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ABSTRACT 


Information  sharing  can  result  in  emergent  behaviors  that  affect  the  safety  properties 
associated  with  overt  information  flows.  Secure  cross-domain  integration,  involving  the 
safety  properties  of  both  individual  domains  and  the  information  dissemination  across 
those  domains,  can  result  in  leakage  of  information  during  the  brokering  of  that 
information  in  an  enterprise-level,  multilevel  secure  (MLS)  system  using  mixed  model 
access  control.  Existing  access  control  models  do  not  address  this  problem.  To  address 
this  gap,  we  developed  a  technique  for  building  compositional  models  that  combine  both 
role-based  access  control  and  traditional  MLS-based  Bell-LaPadula  models  to  provide  for 
a  high-assurance  MLS  system  access  controller.  However,  such  compositional  models 
introduce  information  rights  proliferation  during  the  specification  of  high-assurance 
security  requirements  and  the  security  policy  to  provide  for  safety  within  the  system. 
We  addressed  that  problem  with  a  technique  that  leverages  RuleML  to  specify 
declassification  policies  for  securing  information  exchange  between  different  security 
levels  of  disparate  access  control  models.  The  technique  supports  the  tranquility  principle 
allowing  for  desired  information  flows  while  not  violating  the  overall  security  policy  of 
the  system.  We  demonstrated  the  technical  feasibility  of  using  both  of  these  techniques, 
using  as  our  example  application  cross-domain  information  sharing  in  conducting 
Maritime  Domain  Awareness  operations. 
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I. 


INTRODUCTION 


In  his  testimony  to  the  Senate  in  February  2008,  Viee  Admiral  John  Michael 
McConnell,  The  Director  of  National  Intelligence,  offered: 

The  U.S.  information  infrastructure  including  telecommunications  and 
computer  networks  and  systems,  and  the  data  that  reside  on  them  is  critical 
to  virtually  every  aspect  of  modem  life.  Therefore,  threats  to  our  IT 
infrastmcture  are  an  important  focus  of  the  Intelligence  Community.  As 
government,  private  sector,  and  personal  activities  continue  to  move  to 
networked  operations,  as  our  digital  systems  add  ever  more  capabilities,  as 
wireless  systems  become  even  more  ubiquitous,  and  as  the  design, 
manufacture,  and  service  of  information  technology  has  moved  overseas, 
our  vulnerabilities  will  continue  to  grow.  [1] 


Protecting  both  the  information  infrastmcture  and  the  processing  of  data  is  a  critical 
information  assurance  (lA)  concern.  Information  sharing  via  an  automated  information 
system  (AIS)  requires  that  the  AIS  enforce  confidentiality,  integrity,  and  availability  of 
the  security  policy^  in  the  applicable  domain.2  Enforcing  security  policy  is  challenging 
when  the  data  can  flow  between  security  domains  and  the  information  systems  permit 
data  at  different  levels  of  sensitivity  to  be  accessed  and  stored  on  the  same  set  of 
computing  nodes.  A  cross-domain  security  architecture^  delineates  the  allowable 
information  flows  between  information  systems.  Consequently,  such  an  architecture,  if 
constmcted,  would  support  government  and  military  information  systems  requiring 
multiple  levels  of  security  to  support  full  spectmm  operations  in  the  ongoing  Long  War 
(formerly  the  Global  War  on  Terror)  and  to  meet  the  needs  of  our  military  and 
government  organizations  at  the  highest  levels  of  lA.  These  multilevel  secure  systems 

1  A  security  policy  is  a  set  of  rules  that  specify  how  information  and  resources  are  managed,  protected, 
and  distributed  [2]. 

2  A  domain  is  a  logical  structure  of  resources  or  nodes  working  under  the  same  security  policy  and 
management  [2].  Examples  of  domains  are;  (1)  a  different  classification  level  such  as  the  Secret  level  (2)  a 
separate  management  group  such  as  the  U.S.  Army. 

3  Security  Architecture  is  an  architecture  supporting  the  primary  purpose  of  fulfilling  security 
requirements  in  accordance  with  an  established  security  policy  to  provide  a  predetermined  level  of  tmst 

[3]. 
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require  assurances^  that  they,  in  fact,  offer  protection  of  data  and  services  between  users, 
components  and  interfaces  of  varying  levels  of  confidentiality,  integrity  and  availability. 
Intelligence  Community  Directive  (ICD)  503,  “Information  and  Information  System 
Governance”  establishes  the  requirements  and  controls  necessary  for  an  information 
system  to  achieve  hierarchically-defined  levels  of  assurance,  in  addition  to  outlining  the 
process  for  the  certification  and  accreditation  (C&A)  of  multilevel  secure  (MLS)  systems 
[4],  The  certification  criteria  for  confidentiality,  integrity,  and  availability  to  meet  the 
updated  ICD  503  High-High-High  (H-H-H)  assurance  level  have  a  stringent  list  of 
requirements  for  each  facet.  Developing  systems  to  meet  all  of  the  security  requirements 
of  the  policy  directives,  while  also  meeting  all  other  types  of  requirements,  is  a  challenge 
for  software  and  systems  engineers.  There  are  two  particular  access  control  models  in 
commercially  available  trusted  products  and  DOD  systems  that  will  be  used  as  the  focus 
for  this  research:  Bell-LaPadula  (BLP)  and  role-based  access  control  (RBAC). 
Information  systems  utilizing  the  BLP  model  are  not  sufficient  to  provide  the  level  of 
data  granularity  and  “need  to  share”  capability  required  within  a  security  domain.  Nor  is 
RBAC  sufficient  because  it  does  not  readily  accommodate  access  control  across  multiple 
security  domains.  What  is  needed  are  MLS  systems  utilizing  mixed-model  access  control, 
combining  the  features  of  the  BLP  and  RBAC  models  to  support  net-centric  enterprise 
services  for  sharing  information  [5]. 

One  possible  solution  arose  from  a  U.S.  Navy  Tactical  Exploitation  of  National 
Capabilities  (TENCAP)  project  named  Radiant  Alloy.  In  this  type  of  mixed  model  access 
control  system  architecture,  the  Information  Broker  (IB)  is  an  integral  element.  For  an 
enterprise-level,  service-oriented  architecture  (SOA)-based,  MLS  AlS-supporting  mixed 
model  access  control,  the  IB  plays  the  role  of  information  management  controller.  The  IB 
is  the  intermediary  between  the  requester  of  the  information  and  the  data  repositories. 
The  IB  provides  the  data  and  at  the  same  time  protects  the  anonymity  of  the  source  of  the 
data.  This  anonymity  is  accomplished  because  the  IB  is  effectively  operating  as  a  middle¬ 
man  and  collecting  the  data  from  multiple  repositories.  Thus,  no  attribution  is  linked  to  a 

4  Assurance  is  the  confidence  that  an  entity  meets  its  security  requirements,  based  on  specific  evidence 
provided  by  the  application  of  assurance  techniques  [3], 
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particular  source  for  any  of  the  information  response.  The  responsibility  of  the  IB  is  “to 
facilitate  the  exchange  of  data  between  disparate  applications”  [6].  The  IB  is  an 
architectural  element  that  mediates  access  between  differing  data  sources  without 
requiring  a  custom  connection,  while  also  enabling  the  sharing  of  data  between 
information  systems,  as  depicted  in  Figure  1. 
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Figure  1.  Information  Broker  System  Architecture,  after  [7] 


The  IB  orchestrates  and  logs  all  of  the  system-level  access  requests  and  responses. 
The  IB  mediates  all  user-level  access  requests  and  serves  as  a  Policy  Enforcement  Point 
(PEP),  if  directed  to  do  so  by  the  Policy  Decision  Point  (PDP).  The  PDP  is  responsible 
for  authorization  decisions,  and  resides  in  between  the  subjects,  PEPs  and  the  resource 
managers.  The  IB  requests  data  through  the  Trusted  Database  Connector  (TDC)  and 
corresponding  data  stores  to  fulfill  user  requests.  If  required  by  policy,  the  IB  must 
maintain  the  anonymity  of  the  data  origin,  and  orchestrating  the  ability  of  a  user  to  write 
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back  to  a  data  store  that  may  be  of  a  lower  elassifieation  level  (so  the  user  eannot  infer 
the  origin).  This  involves  the  replieation  of  the  IB  service  at  all  sensitivity  levels  and 
having  additional  services  that  allow  interaetion  between  the  IBs  without  alerting  users 
and  without  impaeting  the  inviolability  of  the  data.  The  IB  is  also  aceessible  from  all 
possible  platforms  and  environments,  and  provides  mandatory  access  eontrol  for  MLS 
based  on  a  hierarchical,  lattice-based  aceess  eontrol  model  [6].  The  information  broker  is 
intended  to  be  a  highly  trustworthy  component  of  a  system,  responsible  for  dealing  with  a 
myriad  of  clearanees,  elassifications,  and  eompartments. 

Clearly,  the  IB  is  the  eentral  service  of  the  system  and  must  rely  on  the 
orehestration  of  several  other  serviees  to  fulfill  its  own  role.  However,  each  of  these 
funetions  of  the  IB  must  be  provided  with  some  level  of  assurance  that  it  meets  the 
seeurity  requirements  of  ICD  503.  The  specification  and  management  of  aecess  eontrol  is 
fundamental  to  the  IB  role.  This  role  becomes  more  ehallenging  to  perform  with  the 
added  eomplexity  of  having  mixed  aceess  eontrol  models.  The  added  complexity  of 
relationships  necessitates  the  establishment  of  guarantees  against  information  leakage 
(non-interferenee)  for  a  eompositionaL  aeeess  controller.  With  this  type  of  system,  we 
diseover  a  non-eompositional  property;  that  is,  even  if  all  components  would  not  leak 
information  individually,  the  combination  thereof  may  enable  information  leakage  via 
overt  channels.  This  aspect  of  safety  for  mixed  aceess  eontrollers  is  an  essential  property 
for  eross-domain  MLS  solutions.  This  researeh  does  not  explore  the  leakage  of 
information  via  covert  channels,  but  rather  provides  for  policy-based  prevention  of  overt 
information  flows  that  eompromise  the  system’s  information  flows.  The  term  “safety”  as 
used  here  refers  to  protection  provided  by  a  system  against  leakage  of  information. 
Formal  definitions  of  safety  and  other  key  terms  are  given  in  the  background  section  of 
this  chapter. 


5  Compositional  refers  to  the  combination  of  disparate  access  control  systems  and  security  policies 
into  an  aggregated  information  system. 
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A.  STATEMENT  OF  THE  PROBLEM 

Information  obtained  first,  or  shared  appropriately  within  an  organization,  helps 
an  enterprise  maintain  a  competitive  advantage  over  adversaries,  where  real-time  data 
feeds  and  data  fusion  aid  in  obtaining  information.  Other  things  being  equal,  information 
supremacy  is  essential  to  winning  wars  when  the  right  information  is  shared  at  the  right 
time,  and  the  risk  of  sharing  information  with  the  wrong  individuals  is  acceptably  low  to 
avoid  catastrophic  consequence  [8],  With  multiple  information  sources  and  the  ever- 
increasing  volume  of  data  that  is  generated  in  real  time  (or  near  real  time)  and  stored, 
enabling  correlation  and  extracting  information  becomes  a  daunting  challenge.  The  use  of 
business  intelligence  and  analytics  (BIA)  creates  an  opportunity  for  a  real-time  analytical 
engine  to  scan  a  broad  set  of  unique  data  sources,  identify  common  patterns  in  the  data, 
translate  those  patterns  into  events,  and  then  correlate  and  resolve  those  events  to  specific 
and  actionable  information.  Traditional  approaches  to  this  big  data  analytic  challenge 
have  relied  on  batch  retrieval  and  relational  schemas  combined  into  a  structured  analysis, 
but  these  do  not  account  for  the  larger  scale  requirements  of  real-time  streaming  data  and 
the  correlation  to  find  hidden  relationships  and  useful  information  from  seemingly 
useless  data,  as  is  found  in  a  BIA  tool. 

The  ability  to  gain  superiority,  either  economically,  politically,  militarily,  or 
otherwise  through  the  processing  and  fusion  of  unclassified  data  and  classified  data  to 
produce  usable  information  that  is  shared  across  domains  is  the  key  impetus  underlying 
the  United  States’  National  Security.  For  instance.  Maritime  Domain  Awareness  (MDA) 
is  defined  by  the  U.S.  Department  of  Homeland  Security  as  the 

effective  understanding  of  anything  associated  with  the  global  maritime 
domain  that  could  impact  the  United  States’  security,  safety,  economy,  or 
environment... MDA  is  a  key  component  of  an  active,  layered,  maritime 
defense-in-depth.  Maritime  domain  awareness  will  be  achieved  by 
improving  our  ability  to  collect,  fuse,  analyze,  display,  and  disseminate 
actionable  information  and  intelligence  to  operational  commanders  and 
decision  makers.  [9] 

One  arena  where  timely  sharing  of  information  is  critical  is  cross-domain 
integration,  which  refers  to  subjects  sharing  information  across  two  or  more  security 
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domains.  A  real-world  example  of  this  integration  lies  with  the  distribution  of 
intelligence  indicators  related  to  malware  and  Advanced  Persistent  Threat  (APT)  actors 
in  the  context  of  national  security.  This  sharing  between  government,  the  defense 
industrial  base  (DIB),  and  other  industry  partners,  like  Symantec  and  McAfee,  requires  a 
cross-domain  system  to  integrate  the  repositories  of  each  proponent.  Secure  cross-domain 
integration  requires  safety  of  individual  domains  as  well  as  safety  of  information 
dissemination  across  those  domains.  These  domains  may  be  governed  by  differing  access 
control  models  and  different  security  levels  of  the  same  MLS  domain.  Consequently, 
sharing  information  between  them  should  be  done  so  that  it  does  not  violate  safety 
criteria  of  the  access  controller  that  governs  the  concerned  domain  and  does  not  create 
covert  channels  enabling  leakage  of  information.  Information  dissemination  safety  must 
work  with  disparate  access  controllers  as  well  as  varying  declassification  policies  and 
rules  between  domains.  Currently,  we  have  many  differing  levels  of  security,  but  those 
levels  are  all  separate.  These  systems  are  traditionally  based  on  the  BLP  model  and  do 
not  allow  for  information  dissemination  across  domains.  Human  declassifiers  and  sneaker 
nets^  can  be  used  to  transfer  information  between  domains;  however,  these  mechanisms 
are  inefficient  and  impractical  in  today’s  highly  connected  environment  hosting  time- 
critical  applications.  Inherent  with  cross-domain  information  sharing  is  the  risk  of  data 
leakage  between  domains.  Each  domain  employs  its  own  security  policies  and  access 
control  model,  which  can  result  in  uncontrolled  observability^  between  domains.  This 
type  of  leakage  violates  information  flow  policy,  as  well  as  the  safety  of  the  system 
overall. 

The  current  architectures  using  mixed  model  access  controllers  between  domains 
are  not  sufficient  and  the  singular  examination  of  domains  for  safety  is  also  not  sufficient. 
The  composition  of  access  controllers  can  result  in  emergent  violations  of  safety  within 


6  Sneaker  net  refers  to  a  manual  work  around  for  the  transfer  of  information  between  information 
systems,  where  a  user  carries  some  type  of  physical  media  with  information  copied  from  one  system  to 
another  for  input. 

7  Observability  refers  to  the  visibility  of  the  results  of  a  change  and  in  this  research  refers  to  how 
information  in  one  domain  can  be  inferred  or  viewed  from  outside  of  the  domain  or  from  separate 
permission  subsets  within  the  domain. 
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or  between  domains.  It  is  from  this  laek  of  safety  resulting  from  the  eomposition  of 
access  controllers  that  we  realize  an  information  flow  and  information  leakage  problem 
that  requires  a  re-architecting  of  the  mixed  model  access  controller  to  prevent  the 
leakage.  As  a  critical  element  of  this  re-architecting,  we  need  to  integrate  an  Information 
Declassifier  (ID)  element  into  the  architecture  to  handle  inconsistencies  and  emergent 
weaknesses  in  the  security  policy  that  arise  from  the  composition  of  access  control 
models.  We  must  also  develop  and  enforce  specific  rules  and  policies  for  the  ID  at  every 
domain  to  allow  for  the  desired  level  of  information  sharing  while  still  protecting  the 
safety  of  the  system  and  the  information  flow.  We  propose  using  RuleML  as  a  means  to 
specify  information  flow  control  policies  between  security  domains.  Execution  RuleML 
[10]  specifies  Prolog- like  rules  that  use  a  XML-like  syntax,  and  consequently  are 
valuable  for  use  in  SOA.  By  re-architecting  the  mixed  model  access  controller,  and 
specifying  the  ID  policies  and  rules,  we  can  regain  the  safety  of  our  information  flows 
within  the  AIS  and  partially  prevent  information  leakage  between  domains. 

B.  HYPOTHESIS 

RuleML  can  be  used  as  a  policy  specification  language,  based  on  a  UML  Use- 
Case  analysis  that  supports  mixed  model  access  controllers  for  a  high  assurance,  MLS, 
SOA-based  system,  to  prevent  information  leakage  and  regain  safety  that  is  compromised 
by  system  behaviors  that  emerge  from  the  composition  of  two  or  more  different  access 
control  models. 

This  hypothesis  will  be  tested  with  a  proof  of  concept  information  broker  and 
information  declassifier  ruleset  developed  to  support  the  MDA  Use-Case  scenarios  that 
use  executable  RuleML.  The  execution  trace  of  the  rules  will  demonstrate  the  efficacy  of 
the  IB  to  redirect  information  flows  using  RuleML  and  prevent  information  leakage. 

C.  BACKGROUND 

Access  control  systems  are  expected  to  provide  safety  guarantees  as  the  basis  for 
trust  and  the  overall  assurances  in  the  system.  The  access  controls  are  responsible  for 
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managing  all  direct  accesses  to  the  system  resources  (objects^)  according  to  the  rules  and 
assigned  by  the  security  policy  and  the  access  control  model  [11].  An  access  control 
model  can  be  separated  into  many  logical  categories:  discretionary  access  control  (DAC), 
mandatory  access  control  (MAC),  Role-based  Access  Control  Systems  (RBAC), 
Attribute-Based  Access  Control  Systems  (ABAC),  etc.  These  subject-centric  access 
control  models  provide  a  framework  that  dictates  how  subjects  can  access^  objects  in  the 
system.  Other  systems  include  capability-based  systems,  where  each  object  has  a  list  of 
capabilities  that  are  required  to  be  possessed  by  any  user  of  the  object.  DAC  systems 
allow  the  user  to  control  access  rights  to  the  objects  that  they  own,  where  this  ability  to 
change  rights  is  subject  to  some  set  of  rules,  which  can  change  during  the  course  of 
operation  of  the  system.  Because  of  this,  it  is  possible  to  bypass  access  restrictions  and 
does  not  provide  an  assurance  for  the  protection  of  data  in  the  system.  Once  the  user 
accesses  data,  the  system  can  no  longer  control  what  the  user  does  with  the  data  (e.g., 
copy,  move).  The  discretionary  access  control  model  then  allows  for  the  transfer  or 
propagation  of  data  in  violation  of  the  original  security  policy.  Mandatory  access  control 
policies  typically  define  a  set  of  allowed  access  rights  of  subjects to  objects  within  a 
particular  domain,  and  assume  that  the  other  objects  are  not  allowed  access.  MAC 
policies  are  enforced  by  the  system  and  not  relegated  to  the  user  for  access.  However, 
there  are  systems  specified  using  prohibitions,  where  the  policy  says  which  subjects  are 
prohibited  from  accessing  the  resources,  and  all  other  subjects  are  allowed  access.  In 
MAC  systems,  subjects  within  the  system  are  assigned  sensitivity  labels  according  to 
their  level  of  trust,  and  objects  are  similarly  assigned  labels  according  to  the  level  of  trust 
that  would  be  required  of  a  subject  to  access  the  information  in  the  object.  A  user  is 
bound,  during  a  specific  session,  to  one  or  more  subjects  at  a  defined  sensitivity  level. 
This  binding  is  constrained  by  the  user’s  clearance  level  and  the  security  level  of  the 


8  Objects  are  entities  that  contain  or  receive  information. 

9  Access  is  defined  as  a  subject’s  ability  to  perform  some  action  such  as  read,  write,  copy,  move, 
delete,  and  execute  an  object. 

10  Subjects  are  active  entities,  generally  in  the  form  of  a  person,  program,  process,  or  device  that  cause 
information  to  flow  among  objects,  or  that  change  the  state  of  the  system. 
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interface  or  terminal  they  are  using,  for  the  duration  of  that  session.  These  subject  labels 
are  compared  against  that  of  an  object,  which  the  user  might  want  to  gain  access  to;  if  the 
subject  label  is  equal  to  or  higher  than  that  of  the  object,  the  user  may  access  the  object. 
MAC  models  are  representative  of  a  MLS  system,  like  a  military  security  system  based 
on  the  Bell-LaPadula  model,  where  objects  and  subjects  are  ordered  based  upon  their 
classification  levels  (Classified,  Secret,  etc.)  and  users  are  granted  access  to  objects  based 
on  the  relationship  between  the  clearance  level  they  possess,  and  the  classification  level 
of  the  object. 

The  safety  guarantee  relates  to  the  aspect  of  information  flow  wherein 
information  directly  refused  to  a  user  cannot  be  indirectly  obtained  by  executing  a  set  of 
operations.  Harrison  et  al.  [12]  defined  authorization  systems  that  allowed  the 
modification  of  access  rights,  along  with  the  ability  for  creating  and  deleting  subjects  and 
objects  within  the  system.  The  safety  concept  introduced  in  [12]  is  that  that  access  to  an 
object  within  the  system  is  impossible  without  the  concurrence  of  the  owner  of  that 
object.  Since  an  owner  in  a  DAC  system  may  extend  rights  to  an  object  that  in  turn  may 
be  given  away  without  the  owner’s  knowledge,  no  protection  system  can  be  safe  by  this 
definition.  It  is  shown  in  [12]  that  it  is  generally  undecidable  whether  “given  an  initial 
access  matrix,  there  is  some  sequence  of  commands  in  which  a  particular  generic  right  is 
entered  at  some  place  in  the  matrix  where  it  did  not  exist  before.”  Given  an  access  matrix 
M  and  a  right  r  (from  a  set  of  rights  R),  verifying  the  state  of  M  with  respect  to  r  is 
undecidable.  An  additional  aspect  of  safety  that  must  be  addressed  for  an  MLS  system  is 
leakage  from  a  covert  channel.  A  covert  channel  utilizes  shared  resources  in  a  system  as  a 
path  of  communication  to  transfer  information.  This  is  an  unintended  path  from  the 
original  system  design,  but  can  be  realized  as  either  a  storage  channel  or  a  timing  channel 
[3].  In  an  information  system,  the  non-existence  of  a  covert  channel  cannot  be  proven. 
The  amount  of  information  that  can  be  transmitted  via  a  covert  channel  affects  the 
severity  of  that  channel  to  the  security  policy. 

Bishop,  in  [3],  defines  secure  versus  safe  with  respect  to  the  level  of  abstraction 
and  implementation.  Secure  and  non-secure  are  used  to  refer  to  the  actual  implementation 
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of  a  system,  while  safety  references  the  abstract  security  modehh  Under  these 
definitions,  we  can  have  a  secure  system  that  will  correspond  to  an  abstract  model  that  is 
safe  for  all  rights,  but  if  we  have  a  safe  model,  we  do  not  necessarily  ensure  a  secure 
system  [3],  Bishop  also  adds  to  the  definition  of  safety  from  [12]  and  further  defines 
information  leakage.  Fundamental  to  these  concepts  is  the  access  control  matrix  model, 
which  is  the  simplest  framework  for  describing  a  protection  system.  An  access  control 
matrix  views  a  system  in  terms  of  the  set  of  protected  entities,  contained  in  the  set  of 
objects  O;  subjects  S  is  a  set  of  active  objects,  such  as  users  and  processes;  and  the  rights 
between  subjects  and  objects  drawn  from  a  matrix  A,  where  the  set  of  rights  R  in  each 
entry  a{s,o\  where  s  E  S,o  E  O,  and  a{s,o\  ^  R.  A  matrix  A,  captures  entity  relationships 
where  rights  drawn  from  R  get  assigned  to  each  entry  a{s,o\.  The  protection  states  of  a 
system  are  then  represented  by  the  triple  (S,  O,  A).  Leakage  occurs  when  a  generic  right  r 
E  R  is  added  to  an  element  of  the  access  control  matrix  not  already  containing  r.  The  set 
of  authorized  states  for  the  system  are  those  in  which  no  command  or  set  of  commands 
c{xi,  ...,  Xn)  can  leak  r.  A  system  is  termed  safe  with  respect  to  the  right  r  if  the  system 
can  never  leak  r  [3].  Safety  as  described  in  [3]  is  critical  for  cross-domain  solutions 
(CDS).  CDS  must  employ  access  controls  that  guarantee  safety  in  order  to  prevent  the 
inadvertent  transfer  or  disclosure  of  sensitive  or  classified  information.  Currently,  no 
safety  results  exist  for  mixed  model  access  controllers  like  that  envisioned  for  use  in  the 
prototype  system  named  Radiant  Alloy.  Through  the  mixed  access  control  modeling  of 
the  security  requirements and  the  security  policy'^  we  can  provide  some  assurances 


1 1  Security  model  is  a  framework  that  outlines  the  requirements  necessary  to  properly  support  and 
implement  a  specific  security  policy.  [2]  The  model  depicts  the  logic  and  rules  that  must  be  implemented  to 
support  the  security  policy,  and  is  a  mapping  of  the  abstract  goals  of  the  policy  into  rules  that  the  system 
must  follow. 

12  A  security  requirement  consists  of  both  functional  requirements  where  it  is  a  statement  of  some 
security  function  or  security  feature  that  should  be  implemented  in  a  system;  and  a  non-fimctional 
requirement  which  is  a  statement  of  a  constraint  or  expected  behavior  that  applies  to  a  system,  and  may 
refer  to  the  emergent  properties  of  the  software  that  is  being  developed  or  to  the  development  process.  [13] 

13  A  security  policy  is  a  statement  of  what  is,  and  what  is  not,  allowed.  [3];  a  statement  that  outlines 
how  entities  access  each  other,  what  operations  different  entities  can  execute,  what  level  of  protection  is 
required,  and  what  actions  should  be  taken  when  the  requirements  are  not  met.  [2]  The  security  policy 
outlines  goals  without  regard  for  how  they  will  be  accomplished. 
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about  the  safety  within  the  system.  This  will  be  done  by  a  constraction  of  safety  by 
definition  within  the  context  of  the  system  architecture  using  use,  misuse,  and  security 
use  cases. 

A  greater  amount  of  work  to  verify  the  correctness  of  an  MLS  and  a  much  higher 
cost  is  necessary  due  to  the  complexity  of  the  system.  A  system  is  considered  to  operate 
in  MLS  mode  when  it  permits  two  or  more  classification  levels  of  information  to  be 
processed  simultaneously  and  when  all  users  do  not  have  the  appropriate  clearance  to 
access  all  of  the  information  processed  by  the  system  [2].  An  MLS  system  has  added 
complexity  in  maintaining  a  separation  of  data  and  preventing  unsafe  or  prohibited 
actions  on  objects  within  the  system.  The  additional  requirements  necessary  to  meet  a 
more  stringent  security  policy  and  greater  assurances  required  of  a  MLS  system,  affect 
the  resulting  security  model  and  ultimately  the  implementation  of  that  model  in  the  final 
system.  This  complexity  becomes  apparent  with  the  implementation  of  the  access  control 
model  for  the  system  itself  The  greater  complexity  of  the  MLS  access  controller  makes  it 
harder  to  test  and  evaluate  under  all  possible  combinations  of  system  accesses  and  subject 
to  object  pairings,  and  thus  harder  to  provide  assurance  of  its  secure  functionality. 
However,  modeling  methods  have  not  kept  pace  with  the  rise  in  complexity,  thus  creating 
and  exacerbating  the  separation  of  the  system  development  and  the  underlying  security  of 
the  system  [14].  Additionally,  those  who  are  not  security  practitioners  might  view  the 
added  security  requirements,  necessary  to  meet  a  High  assurance  level,  as  an 
inconvenience  that  can  be  dealt  with  later.  An  enforcement  and  orchestration  mechanism 
must  be  used  to  provide  the  integration  of  security  policy  and  architecture  in  a  SOA- 
based  system.  Access  must  be  strictly  controlled  to  enforce  these  security  policies  and 
maintain  core  data  security.  Assurance  of  the  system’s  functionality  to  support  multiple 
levels  of  security  hinges  on  four  elements:  the  access  control  model,  the  security  kernel, 
the  information  broker,  and  the  information  declassifier. 
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D.  SIGNIFICANCE  OF  THE  PROBLEM 

MDA  and  similar  national  security  related  missions  require  sharing  of  information 
of  multiple  levels  of  sensitivity  across  security  enclaves.  This  has  become  an  evolving 
challenge  to  maintain  necessary  information  flows  as  current  access  control  models  are 
not  sufficient  to  support  desired  cross-domain  solution  (CDS)  requirements.  The 
compositional  model  introduces  emergent  challenges  for  information  rights  proliferation 
(i.e.,  information  leakage)  as  we  model  high-assurance  security  requirements  and  the 
security  policy  to  provide  for  safety  within  the  system.  In  this  research,  we  specify  safety 
properties  of  the  mixed  model  access  controller  and  the  rules  necessary  to  implement  an 
information  declassifier  using  a  UML-based  Use-Case  security  analysis  and  use  RuleML 
as  a  means  to  specify  information  flow  control  policies  between  security  domains. 
Ruleset  checks  are  also  provided  to  demonstrate  that  the  safety  property  for  information 
flows  still  holds  with  the  addition  of  the  information  declassifier  to  the  system 
architecture.  By  following  this  approach,  we  can  re-architect  an  access  controller  to 
ensure  security  requirements  are  achieved  without  the  specified  policy  violations  or 
leakage  of  information  resultant  from  the  compositional  model,  thus  regaining  safety. 

E.  RESEARCH  APPROACH 

The  process  flow  planned  for  conducting  this  research  is  shown  in  Figure  2  and 
includes  the  following  steps: 

1 .  Develop  a  Concept  of  Operations  as  a  Basis  for  a  Security  Po/icy-develop 
realistic  Use  Case  and  Misuse  Cases  that  exercise  the  system  requirements 
and  challenge  the  security  specifications  for  a  mixed  model  access  control 
system  using  the  BLP  and  RBAC  models. 

2.  UML-based  Use  Case  Analysis  to  Generate  a  Security  Use  Case  and  Re¬ 
architecting  Z)eve/opment-determine  the  Security  Use  Case  necessary  to 
prevent,  mitigate,  and  detect  the  Misuse  Cases  while  still  permitting  all 
Use  Cases,  to  maintain  the  safety  of  information  flows  within  our  system. 
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3. 


System  Re-architecting  Development— AQtQrmmQ  the  re-architecting 
necessary  to  meet  the  Security  Use  Case  requirements. 

a.  Provide  Sequence  Diagrams  for  the  Security  Use  case  in  the 
revised  architecture. 

b.  Develop  sample  data  sets  as  a  basis  for  the  underlying  system 
model. 

c.  Develop  sample  Vessels,  Queries  and  Alerts  using  XML 

d.  Define  Information  Declassifier  rules  using  RuleML 
4.  Safety  f?e/znement-demonstrate  what  constitutes  safety  in  our 

mixed  model  access  control  system  and  how  the  architecture 
supports  the  concept  based  on  the  re-architecting. 

5.  Rule  Verification,  Regression  Testing,  and  Proof  of  Concept  Simulation- 
use  template  system  in  a  standard  Maritime  Domain  Awareness  scenario 
as  a  proof  of  concept  and  demonstrate  technical  feasibility  of  the 
verification  of  the  re-architecting  and  the  specification  of  the  security 
policy  using  RuleML  in  a  simulation  of  the  various  scenarios. 
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Figure  2.  Methodology  and  Approach  Flow 
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F. 


CONTRIBUTIONS  OF  THIS  RESEARCH 


As  described  above,  the  composition  of  access  controllers  in  a  system  may  result 
in  emergent  behaviors  that  violate  the  safety  property  of  that  system.  We  propose  a 
methodology  for  modeling  these  behaviors  and  re-architecting  a  system  to  detect,  or 
mitigate  these  emergent  behaviors.  We  also  provide  a  sample  framework  that  validates 
the  re-architecting  and  uses  a  rule-based  service  to  prevent  the  overt  information  flows 
and  regain  safety  within  our  system.  We  demonstrate  the  adequacy  of  RuleML  for 
modeling  and  reasoning  about  access  control  security  policy  in  a  cross-domain  context. 
The  specific  contributions  of  this  work  are  listed  below: 

1.  Developed  and  Used  a  New  Methodology  for  Security  Analysis  using 
UML-based  Use  Case  Analysis  to  Direct  the  Re-architecting  of  a 
System  for  the  Preservation  of  Safety 

The  methodology  of  security  analysis  using  UML  Use  and  Misuse  Cases,  allows 
for  tailoring  of  security  policies  and  mitigating  the  “highest  cost”  risks  for  information 
flow  while  still  enabling  trusted  sharing.  UML-based  Use  Case  security  analysis  has  not 
been  applied  in  a  MLS,  SOA-based  venue  and  this  work  utilizes  that  approach  as  an 
exemplar  to  provide  for  a  greater  access  to  information  and  increased  sharing  among 
disparate  security  domains.  In  order  to  support  inviolate  information  flows  to  the  security 
policy,  and  to  overcome  the  tranquility  property  associated  with  traditional  MLS  systems, 
we  demonstrate  that  Radiant  Alloy  needs  to  use  an  information  declassifier. 

2.  Developed  a  New  Process  to  Allow  for  the  Prioritization  of 
Information  Flows  and  the  “Safe”  Composition  of  Mixed  Access 
Control  Models  through  a  Re-architecting  of  the  System 

Through  the  process  of  prioritizing  the  information-flow  needs  within  a  system, 
we  can  tailor  the  composition  of  different  access  control  models  to  support  required 
flows.  This  effectively  opens  the  information  sharing  infrastructure  to  more  DOD 
organizations  and  provides  a  means  for  cooperation  and  more  real-time  passing  of 
information  between  agencies.  This  process  also  helps  engineers  and  developers  combine 
“best-of’  practices  in  their  design  and  implementation  of  an  AIS.  The  idea  of 
prioritization  is  based  on  the  risk  analysis  and  risk  tolerances  of  the  stakeholders.  The 

15 


allowable  “exceptions”  to  our  baseline  policies  are  considered  as  the  only  permissible 
extensions  and  ultimately  determine  what  is  safe  for  the  system.  The  method  shown  in 
this  research  uses  RuleML  to  enforce  this  policy.  The  need  for  sharing  and  the  need  to 
maintain  security  must  be  balanced  to  provide  an  operationally  useful  system  that  will 
still  uphold  the  desired  and  specified  safety  for  information  flows. 

3.  Created  a  New  Process  for  the  Development  of  Business  Process 
Rules,  using  RuleML  to  Specify  Allowed  Information  Flows  and  to 
Restrict  Flows  Enabling  Leakage  of  Information  from  Emergent 
Behaviors  and  Facilitate  Sharing  between  Information  Systems 

To  support  the  development  of  an  information  declassifier,  we  provide  a  policy- 
based  framework  to  do  so  using  RuleML  [15].  By  developing,  implementing  and 
enforcing  business  process  rules  through  the  use  of  RuleML,  we  realize  a  greater  control 
of  our  information  flows.  The  rule  engine  provides  for  a  greater  granularity  of  Need  (Not) 
to  Share  for  information  within  domains,  facilitating  the  dissemination  of  information  and 
providing  increased  speed  of  information  flow  to  allow  a  greater  use  of  “real-time” 
information,  compared  with  traditional  MAC-only  policies.  Current  systems  cannot 
support  this  level  of  information  sharing  and  traditionally  use  a  workaround  (i.e., 
sneakernet)  to  meet  user  requirements.  The  extension  of  an  open-source  XML-based 
business  process  language  to  facilitate  the  composition  of  access  controllers  and  the 
safety  of  the  associated  models  provides  a  useful  tool  for  software  engineers  in  system- 
architecting  efforts. 

4.  Provided  a  Process  that  Allows  Engineers  to  use  Decision  Tables  or 
Other  Methods  to  Develop  Simple  Propositions  to  Express  Desired 
Process  and  Information  Flows  that  can  be  Formed  into  Executable 
RuleML 

With  the  re-architecting  of  an  information  system,  it  is  necessary  to  provide  a 
convincing  argument  that  the  RuleML  specification  supports  the  system’s  required 
information  flows.  By  creating  business  process  rules  with  RuleML  to  support  the 
sharing  of  information  within  the  system,  we  can  show  that  all  prior  capabilities  and 
intended  flows  are  still  available  to  the  user,  yet  there  are  no  unintended  flows  that  result 
in  violation  of  the  safety  property.  This  is  an  extension  of  the  work  conducted  on  the 
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hook-up  theorem  for  multilevel  security  with  respect  to  inference  control  and  the 
composability  of  restrictiveness  for  security  policies  [41],  This  must  be  done  to  build  a 
basis  of  confidence  for  services  to  be  used  (and  reused)  with  respect  to  the  Information 
Broker  and  its  associated  rule  engine  based  Information  Declassifier  service.  By 
regression  testing,  which  includes  running  the  ruleset  with  a  sample  data  set,  we  can 
verify  that  our  security  use  case  is  correct.  This  is  necessary  to  help  establish  a  basis  for 
certification  of  information  systems  at  high  assurance  levels.  The  rule-based,  Information 
Declassifier  service  helps  to  automatically  provide  Information  Broker  web  services  with 
a  means  of  information  sharing  and  information  filtering  that  is  not  available  within 
individual  access  control  models,  and  to  ensure  the  safety  of  information  flows  in  mixed 
model  access  control  systems.  This  included  the  validation  of  the  concept  system  re¬ 
architecting  through  the  conduct  of  a  regression  testing  verification  and  a  simulation  of 
RuleML  content-based  query  injection  and  filtering,  whose  results  verified  the  rule 
structure  and  usage  of  RuleML  as  a  specification  language. 

G.  OVERVIEW  OF  THE  DISSERTATION 

In  Chapter  II,  we  provide  background  information  on  several  areas  essential  to 
understanding  this  research,  as  well  as  cover  an  assessment  of  previous  work  in  the 
respective  areas. 

Chapter  III  includes  an  introduction  to  the  operational  context  that  we  used  as  a 
basis  for  the  work.  The  service-oriented,  cross-domain  secure  system  is  outlined  as  it 
pertains  to  this  research. 

Chapter  IV  introduces  a  motivating  example  of  why  information  in  a  cross¬ 
domain  context  is  necessary  in  Maritime  Domain  Awareness.  The  Use  Case  scenario  is 
depicted  in  detail,  which  is  the  basis  for  the  re-architecting  and  security  analysis  to 
preserve  safety.  We  describe  the  desired  and  undesired  flows  and  the  rules  necessary  to 
allow  and  prevent  those  flows  accordingly. 

Chapter  V  highlights  the  queries  system  and  alert  messaging  that  are  used  in  our 
prototype  system.  We  describe  the  scenario-based  query  process  and  show  examples  with 
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differing  Web  Services  (WS)  languages,  along  with  the  specification  of  Alert  Messaging 
to  support  the  scenario. 

Chapter  VI  provides  a  summary  of  the  re-architecting  methodology  and  its 
subsequent  rule-based  execution  from  our  prototype  system.  We  briefly  discuss  the 
Security  Use  Case  information  flows  that  were  required  for  the  scenario  and  how  the 
Information  Declassifier  supported  those  requirements.  We  also  provide  a  prototype  of 
the  Information  Declassifier  re-architected  system  through  a  RuleML  policy  specification 
and  its  execution. 

Chapter  VII  highlights  the  contributions  toward  software  engineering  and 
information  assurance  as  well  as  future  directions  of  our  research. 

H.  KEY  FINDINGS 

In  this  research,  we  show  how  the  methodology  for  UML-based  Use  Case 
Analysis  can  be  used  to  elicit  and  model  undesirable  information  flow  properties  within  a 
mixed  access  control  model,  SOA-based,  MLS  system.  This  provides  a  systematic 
approach  to  regaining  safety  and  enabling  trusting  sharing  and  desired  information  flows, 
without  violating  tranquility.  We  also  show  how  this  analysis  can  be  used  to  re-architect  a 
system  to  detect,  mitigate,  or  prevent  undesirable  information  flows,  and  extend  this  re¬ 
architecting  by  adding  rules,  via  RuleML,  to  maintain  and  enforce  the  changes  in  system 
architecture  as  a  security  policy  specification  language.  By  using  RuleML,  we  show  the 
feasibility  of  this  approach  that  can  be  extended  to  other  technologies  or  languages  to 
specify  policy  and  information  flows.  Our  work  provides  for  composing  disparate  access 
control  model  systems,  allowing  for  an  accurate,  security-grounded  process  for  policy 
management.  Composing  different  systems  with  diverse  access  control  models  can  result 
in  information  leakage,  and  consequently,  result  in  the  composed  system  violating  some 
safety  criteria.  We  have  shown  how  this  can  be  addressed  by  introducing  an  information 
declassifier,  of  which  the  de-classification  policies  can  be  written  in  RuleML.  The  use  of 
regression  testing  provides  verification  of  the  content-based  query  injection  and  filtering 
for  the  RuleML  concept  ruleset.  The  functionality  of  the  Information  Declassifier 
mandates  a  response  during  each  step  of  the  rule  firing  order,  requiring  the  use  of 
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reactionary  rules  in  RuleML.  Both  positive  case  and  negative  case  rules  were  established 
and  linked  via  forward  chaining  throughout  the  ruleset  to  create  and  enforce  the  policy 
model.  By  preventing  an  ambiguous  or  a  non-response  from  within  the  ruleset,  we  can  be 
assured  that  the  Information  Declassifier  will  also  return  a  result.  The  MDA  scenario 
provides  a  motivating  example  for  cross-domain  information  sharing.  Finally,  we 
demonstrate  the  use  of  RuleML  rules  to  maintain  information  flow  safety  within  a  system 
through  simulation,  which  verified  the  rule  structure  and  usage. 
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II.  ASSESSMENT  OF  PREVIOUS  WORK 


The  research  described  in  this  dissertation  builds  on  a  variety  of  prior  efforts  to 
construct  multilevel  secure  systems,  enable  information  sharing,  and  realize  the  effective 
implementation  of  security  policies  with  the  support  of  a  service-oriented  architecture. 
This  work  also  builds  upon  the  research  of  McDaniel  and  Tardy  [16]  on  role-based  access 
control  for  MDA  and  that  of  Bennett  [17]  on  defining  a  common  intelligence  picture  for 
MDA.  While  a  large  amount  of  work  has  been  done  related  to  covert  channels  and  the 
exploration  of  blocking  those  channels  via  different  methods,  the  use  of  and  mitigation  of 
covert  channels  is  not  explored  in  this  dissertation  [2,  18-22],  This  research  covers  overt 
information  flows  and  the  prevention  of  information  leakage  resultant  from  the 
composition  of  disparate  systems. 

A.  ACCESS  CONTROL 

Access  controls  are  used  to  verify  that  desired  user  accesses  to  system  objects  are 
authorized.  Part  of  these  access  controls  are  done  with  an  overarching  policy  or  model, 
while  the  secondary  piece,  and  arguably  a  highly  important  one  as  well,  is  the 
enforcement  of  the  policy  via  an  access  control  mechanism.  The  policy  is  used  to  specify 
allowable  actions  within  a  system  and  will  be  the  focus  of  this  research  rather  than  the 
implementation  or  enforcement  mechanism.  The  access  control  policy  ensures  that 
information  does  not  flow  from  one  set  of  subjects  to  another  in  the  system  (e.g.,  Top 
Secret  information  flowing  to  Unclassified),  and  that  there  is  no  path  that  exists  between 
any  two  subjects  through  some  combination  of  objects  or  even  other  subjects.  Because  of 
these  desirable  restrictions,  access  control  must  also  discern  between  various  users  or 
subjects  authorizations,  and  the  objects  (processes,  files,  data,  domains,  etc.)  that  they 
require  access  to.  Also  required  is  the  ability  to  protect  the  subjects  and  objects 
themselves  from  improper  use  or  modification.  With  many  security  models  we  find  an 
underlying  access  matrix  forming  the  basis  for  the  access  control  policy. 

Many  access  control  matrices  exhibit  the  idea  of  ownership  for  objects  within  the 
system.  In  our  SOA-based  system,  we  do  not  rely  on  or  implement  an  ownership  based 
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access  because  of  the  Information  Broker.  The  IB  services  user  requests  and  aets  as  our 
access  eontrol  mechanism.  Inherent  with  this  is  the  idea  that  the  IB  or  the  originating  data 
store  will  have  ownership  of  an  object  and  not  individual  subjects  (users).  This  eliminates 
the  ability  of  subjeets  to  grant  or  revoke  privileges  to  objeets,  since  they  never  have 
ownership. 

1.  An  Access  Control  Matrix 

The  aeeess  eontrol  matrix  (ACM)  is  a  representation  of  policy  and  the  system  at  a 

given  state.  The  aeeess  eontrol  matrix  model  is  typieally  regarding  as  the  simplest 

framework  for  describing  a  protection  system.  An  aeeess  eontrol  matrix  views  a  system 

in  terms  of  the  set  of  protected  entities,  contained  in  the  set  of  objeets  0\  subjeets  S  is  a 

set  of  aetive  objects,  like  users  and  processes;  and  the  rights  between  subjects  and  objects 

drawn  from  a  matrix  A,  where  the  set  of  rights  R  in  eaeh  entry  a\s,o\  where  s  E  S,  o  E  O, 

and  a{s,o\  ^  R.  A  matrix  A,  captures  entity  relationships  where  rights  drawn  from  R  get 

assigned  to  eaeh  entry  a{s,o\.  The  proteetion  states  of  a  system  are  then  represented  by 

the  triple  {S,  O,  A).  Objects  typically  include  fdes,  memory  space,  and  even  processes. 

Subjeets  are  typieally  users,  proeesses,  or  domains  (i.e.,  privileged).  Eaeh  of  the  rights 

speeified  within  the  matrix  differentiates  the  types  of  aetions  that  can  be  performed  on  the 

respeetive  objects.  The  resultant  mapping  of  Subjects  to  Objects,  with  Rights  assoeiated  is 

an  access  eontrol  matrix.  In  [12],  six  primitive  operations  are  defined: 

Enter  r  into  A[s,  o] 

Delete  r  from^[^,  o] 

Create  subject  5 
Create  object  o 
Destroy  subject  s 
Destroy  object  o 

These  primitive  operations  were  shown  in  [12]  to  be  decidedly  safe,  since  they  are 
monotonie  and  that  for  non-monotonic  systems  safety  is  mueh  more  eomplex  and  they 
represent  changes  in  state  for  the  system  in  question.  Monotonicity  refers  to  the  system  in 
question  only  condueting  one  operation  at  a  time  and  this  is  where  the  safety  can  be 
shown.  It  is  these  states  of  the  system  itself  that  we  can  relate  to  safety.  By  not  allowing  a 
system  to  reach  an  unauthorized  state,  we  have  effectively  limited  the  model  to  safe 
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behavior.  However,  a  safe  system  is  not  necessarily  a  secure  system.  Safety  refers  to  the 
model  of  the  system,  while  security  refers  to  the  implementation  of  that  model  in  the 
actual  system.  This  is  the  fundamental  difference  and  security  is  what  is  measured  during 
the  C&A  process. 

2.  Access  Control  Matrix  Safety 

Any  system  that  allows  for  information  sharing  will  have  information  flow 
leakage.  This  leakage  is  often  a  permissible  type,  where  users  will  trust  other  users  with 
access  rights  to  data.  The  safety  guarantee  that  we  need  for  our  systems,  relates  to  the 
aspect  of  information  flow  wherein  information  directly  refused  to  a  user  cannot  be 
indirectly  obtained  by  executing  a  set  of  operations.  Harrison  et  al.  [12]  define 
authorization  systems  allowing  the  modification  of  access  rights,  along  with  the  ability 
for  creating  and  deleting  subjects  and  objects  within  the  system.  The  safety  concept 
introduced,  stated  that  access  to  an  object  within  the  system  was  impossible  without  the 
concurrence  of  the  owner  of  that  object.  Since  an  owner  in  a  DAC  system  may  extend 
rights  to  an  object  that  in  turn  may  be  given  away  without  his  knowledge,  no  protection 
system  can  be  safe  by  this  definition.  They  subsequently  showed  that  it  is  generally 
undecidable  whether,  “given  an  initial  access  matrix,  there  is  some  sequence  of 
commands  in  which  a  particular  generic  right  is  entered  at  some  place  in  the  matrix 
where  it  did  not  exist  before”  [12].  Thus,  given  an  access  matrix  M  and  a  right  r  (from  a 
set  of  rights  R),  verifying  the  state  of  M  with  respect  to  r  is  undecidable.  An  additional 
aspect  of  safety  of  concern  to  a  MLS  system  is  leakage  from  a  covert  channel.  A  covert 
channel  utilizes  shared  resources  in  a  system  as  a  path  of  communication  to  transfer 
information.  This  is  an  unintended  path  from  the  original  systems  design,  but  can  be 
realized  as  either  a  storage  channel  or  a  timing  channel  [3]. 

3.  Safety  Analysis 

The  safety  of  an  access  control  matrix  has  been  shown,  in  general,  to  be  un¬ 
decidable.  Generally,  the  complexity  (of  the  security  verification)  is  tied  to  the  choice  of 
the  security  model’s  abstraction  level,  and  the  design  principles  of  the  security 
architecture  for  the  implementation. 
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The  overarching  security  policy  drives  the  choice  of  the  security  model.  In  this 
case,  the  need  to  provide  access  right  proliferation  across  boundaries,  leads  to  selection  of 
the  Harrison-Ruzzo-Ullman  (HRU)  model.  HRU  provides  access  control  matrices 
combined  with  state  machines  to  enable  security  property  analysis  through  the 
observation  of  state  transitions.  For  a  safety  analysis  of  this,  we  want  to  know  if  it  is 
possible,  given  an  initial  matrix  (M),  that  a  subject  (s)  can  obtain  a  right  (r)  to  an  object 
(o)  in  M.  This  would  entail  a  leakage  problem,  wherein  access  (via  the  rights)  to  an  object 
by  a  subject  is  gained,  without  the  concurrence  of  the  object’s  owner. 

Harrison-Ruzzo-Ullman  analysis  has  been  shown  to  be  decidable  when  the  model 
is  restricted  (e.g.,  mono-operational  operations).  But,  we  cannot  effectively  model  current 
security  policies  with  such  a  restricted  model.  Mono-operational  systems  are  easier  to 
model,  but,  not  as  useful  or  as  expressive  as  required  to  meet  the  modeling  needs  of  a 
complex  policy.  Based  on  the  reduction  methods  proposed,  if  we  can  in  fact  discount  the 
entire  matrix  and  only  represent  sub-matrices  based  on  domain,  then  we  could  gain  a 
reduction  in  state  space.  This  reduction  in  complexity,  if  reduced  sufficiently,  could  then 
be  used  with  fully  automated  safety  analysis. 

Despite  differing  security  domains,  web  services  via  SOA  can  be  used  to  integrate 
these  multiple  domains,  multiple  policies,  and  multiple  enforcement  mechanisms  into  a 
usable  framework.  The  RBAC  model  is  a  candidate  for  implementing  this  policy  in  a 
single  domain,  but  a  compositional  model  that  extends  RBAC  and  uniformly  integrates 
between  domains  would  be  ideal. 

B.  MANDATORY  ACCESS  CONTROL  MODELS 

Mandatory  access  control  models  are  the  most  stringent  for  access  to  objects  and 
resources  in  a  system. 

1.  Bell  and  LaPadula  Model 

The  Bell-LaPadula  (BLP)  Model  is  associated  with  military-style  classification  of 
information  and  is  used  to  enforce  rules  to  provide  confidentiality  protection  [3,  23].  The 
BLP  model  was  developed  to  address  the  security  of  time-sharing  mainframe  systems  and 
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the  leakage  of  sensitive  information,  and  particularly  to  prevent  sensitive  information 
from  being  accessed  in  an  unauthorized  manner.  The  BLP  model  is  a  state  machine 
model  that  enforces  the  confidentiality  aspect  of  access  control,  where  the  state  machine 
is  the  mathematical  basis  to  show  that  the  model  (machine)  will  begin  and  remain  in  a 
secure  state  at  all  times.  The  BLP  model  defines  the  legal  transitions.  The  Basic  Security 
Theorem,  is  “if  a  system  initializes  in  a  secure  state  and  all  allowed  state  transitions  are 
secure,  then  every  subsequent  state  will  be  secure”[2].  This  theorem  is  based  on  two 
fundamental  conditions  of  the  model. 

The  definition  of  the  Simple  Security  condition,  given  in  [23],  states  that  a  user 
can  only  access  objects  assigned  an  equal  or  lower  classification  level  to  that  he  or  she  is 
cleared  for;  this  concept  is  commonly  referred  to  as  “read  down.”  It  can  be  expressed  as: 
S  (Subject)  can  read  O  (Object)  if  and  only  if  lo  <  Is  (/  represents  the  security  clearance) 
and  S  has  discretionary  read  access  to  O  [3]. 

The  *-Property  (Star  Property)  states  that,  to  ensure  that  more  sensitive 
information  is  not  moved  to  less  sensitive  objects  by  malicious  software,  a  subject  cannot 
write  into  an  object  that  is  of  a  lower  classification  level;  this  rule  permits  “write  up”  but 
not  “write  down”  [23].  It  can  be  expressed  as:  S  can  write  O  if  and  only  if  fe^/oand  S 
has  discretionary  access  to  O  [3]. 

In  the  BLP  model,  all  objects  in  the  system  are  assigned  a  sensitivity  level  based 

on  their  classification  level,  and  all  users  are  similarly  assigned  a  clearance  level.  Each 

clearance  represents  a  sensitivity  level  and  all  are  linearly  ordered  (e.g.,  Unclassified, 

Confidential,  Secret,  Top  Secret).  This  model  works  well  for  generic  access  to  an  entire 

information  domain  (e.g..  Secret),  but  to  further  segment  usage  rights  we  need  to  tailor 

the  permission  for  objects  even  further  within  the  domain,  which  allows  us  to  extend  the 

model  by  adding  categories  within  each  classification;  this  is  generally  done  by  using  a 

lattice  as  shown  in  [3,  24]  to  support  the  “need  to  know”  for  users  within  a  classification 

or  through  the  use  of  role-based  access  control  within  each  domain  to  generate  our  mixed 

model  access  control.  Lattices  can  compose  partial  or  total  ordering  among  the  elements 

of  a  set,  where  S  is  a  finite  set  of  elements  and  R  is  a  relation.  A  simple  linear  ordering  of 

security  classes,  shown  in  Figure  3,  falls  into  a  lattice  structure,  where  S  is  a  finite  set  of 
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elements  (e.g.,  S  =  {Unclassified,  Secret,  Top  Secret}),  and  R  is  a  relation  (e.g.,  R  = 
(Unclassified  <  Secret  <  Top  Secret}). 

{Top  Secret} 

1 

{Secret} 

t 

{Unclassified} 

t 

0 


Figure  3.  Linearly  Ordered  Lattice,  from  [3] 

Lattices  can  compose  partial  or  total  ordering  among  the  elements  of  a  set,  where 
S  is  a  finite  set  of  elements  (e.g.,  S  =  (x,  y,  z}),  and  R  is  a  relation  of  those  elements.  This 
nonlinear  structure  allows  for  greater  complexity  in  the  structure  and  for  composing 
structures  with  ordered  sets  and  subsets  among  non-related  objects  [24].  Denning’s 
nonlinear  lattice  example  is  shown  in  Figure  4  [3]. 
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{x,  y,  z} 


Figure  4.  Lattice  Demonstrating  Non-Linear  Ordering,  from  [3] 

By  adding  this  structure,  the  flow  of  information  can  be  controlled  and  secure 
flows  can  be  specified. 

2.  Role-Based  Access  Control 

Role-based  access  control  (RBAC)  is  another  mandatory  access  control  model 
that  uses  subjects,  roles  and  permissions,  as  primitive  entities  and  two  mappings;  subject- 
to-role  mapping  and  role-to-permission  mapping.  The  model  maps  a  subject  to  the  roles 
assigned  to  that  subject  and  the  role  to  the  previously  designated  permission  set.  In  this 
model,  a  subject  obtains  permission  to  act  on  an  object  based  on  permission  assigned  to 
the  role  that  subject  fills.  Each  role  r  is  authorized  to  perform  transactions  in  support  of 
the  role.  This  set  of  actions  is  defined  as,  trans{r).  The  active  role  that  a  subject  is 
performing  is  defined  as,  actr{s),  while  the  authorized  roles  for  a  subject  is  shown 
as,  authr{s).  A  Boolean  predicate  detailing  whether  a  given  subject  s  can  execute 
a  transaction  t,  is  shown  by  canexec{s,  f)  [3].  Given  these  basic  definitions,  we  can 
construct  axioms  to  detail  the  rest  of  the  model.  The  rule  of  role  assignment  shows 
that  if  a  subject  can  execute  any  transaction,  then  that  subject  has  an  active  role; 
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(y/s  e  S)(yt  e  T)[canexec{s,t)  actr(s)  0]  [3],  where  S  is  set  of  all  subjects  and  T  is 
the  set  of  transactions  [3],  The  rule  of  role  authorization  states  that  a  subject  must  be 
authorized  to  assume  its  active  role;  €  S)[actr(s)  c  authr(s)]  [3].  This  rule  prevents  a 
subject  from  assuming  any  arbitrary  role,  and  thus  executing  any  transaction  authorized 
to  that  arbitrary  role.  The  rule  of  transaction  authorization  prevents  a  subject 
from  executing  a  transaction  which  its  current  role  is  not  authorized; 
{\/s  E:  e:T)[canexec(s,t)  ^  t  e:trans(actr{s)y\[3].  Each  of  these  three  rules  serves 

to  restrict  the  transactions  that  can  be  performed  within  the  RBAC  system.  Additional 
roles  can  be  introduced  to  account  for  the  domination  of  roles  and  for  the  concept  of 
separation  of  duty  for  roles.  The  domination  or  containment  rule  can  be  expressed  as;  role 
n  contains  role  rj,  where  n>rj  and  (\/s  e  e  authr{s)  a  >/;.—>  rj  e  authr(s)]  [3]  The 

use  of  a  separation  of  duty  rule  is  critical  for  a  military  AIS  in  which  a  single  user  cannot 
maintain  all  permissions.  This  rule  can  be  expressed  using  two  roles,  r;  and  r2  where 
(\/s  eS)[r^Gauthr(s)^r2^authr(s)][3].  RBAC  can  be  effectively  used  for  limiting 

access  where  the  subject’s  need  to  know  must  be  further  restricted  within  a  security  level. 
RBAC  has  also  been  shown  in  [25]  to  help  provide  safety  guarantees  for  the  leakage 
problem  and  for  the  separation  of  roles  and  subject  authorizations  to  access  data.  RBAC 
provides  for  the  enforcement  of  least  privilege  within  a  system.  Least  privilege  is  a 
design  principle  that  guides  the  overall  design  of  a  system  and  impacts  on  the  choice  of 
security  access  policy  used  and  its  enforcement.  Privileges  are  allocated  to  roles  and  then 
users  are  assigned  to  those  roles.  Interfaces  may  be  constructed  that  are  available  to  only 
certain  subsets  of  the  user  population.  An  audit  mechanism  may  provide  separate 
interfaces  for  the  audit  manager,  the  audit  operator,  and  the  audit  reviewer.  The  interfaces 
provide  the  least  privilege  that  the  user  needs  to  complete  his  or  her  job,  because  each  of 
the  interfaces  would  provide  different  levels  of  functionality  upon  login  and 
authentication. 

In  addition,  least  privilege  can  be  used  for  the  internal  structure  of  the  system. 
One  aspect  is  to  construct  modules  so  that  only  the  elements  encapsulated  by  the  module 
are  directly  operated  upon.  Elements  external  to  a  module  that  may  be  affected  by  the 
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module’s  operation  are  indireetly  aeeessed  through  interaetion  (e.g.,  via  a  function  call  or 
a  service  request)  with  the  module  that  contains  those  elements.  Another  aspect  of 
internal  least  privilege  is  that  the  scope  of  a  given  module  or  component  should  only 
include  those  system  elements  that  are  necessary  for  its  functionality,  and  that  the 
methods  through  which  the  elements  are  accessed  should  also  be  minimal.  Layering, 
modularity  and  information  hiding  are  constructive  techniques  for  least  privilege  that  can 
be  applied  to  the  internal  architecture  of  the  underlying  trusted  foundation  (e.g., 
separation  kernel)  to  improve  the  system’s  resistance  to  penetration.  The  kernel  can  also 
be  configured  to  utilize  protection  mechanisms  such  as  access  control  and  fine-grained 
execution  domains  to  limit  the  ability  of  a  subject  to  perform  only  the  tasks  for  which  it  is 
authorized.  In  a  layered  system  architecture,  enforcement  mechanisms  of  the  most  critical 
policies  depend  on  the  high  assurance  layer. 

An  advantage  of  RBAC  over  DAC  or  BLP  models  is  the  isolation  of 
organizational  jobs  as  roles  and  assignment  of  minimal  permissions  to  complete  a 
particular  job  function.  Each  role  then  defines  a  specific  set  of  operations  that  a  user  with 
that  role  may  perform,  and  a  set  of  objects  that  the  user  may  access.  This  provides  a  level 
of  indirection  between  subjects  and  permissions  and  separates  the  static  time  role  design 
from  the  dynamic  nature  of  obtaining  and  relinquishing  permissions  by  user  and  object 
mappings.  This  results  in  a  relatively  static  system  design,  but  one  where  the  individuals 
filling  roles  may  change  much  more  frequently. 

Kuhn,  in  [43],  shows  how  RBAC  can  be  implemented  on  a  MLS  system  that  uses 
information  flow  policies  corresponding  to  a  lattice.  This  is  done  through  the  use  of  a 
trusted  process  acting  to  manage  roles  for  the  access  control.  RBAC  on  existing  MLS 
demonstrates  reuse  of  current  certified  and  accredited  systems,  but  does  not  offer  the 
level  of  information  sharing  and  extensibility  required  for  modem  homeland  defense. 
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c. 


USE  CASE  ANALYSIS 


Unified  Modeling  Language  (UML)  was  developed  by  the  Object  Modeling 
Group  (OMG)  and  is  an  international  standard  used  for  software  development  [26],  It  is 
known  in  its  current  version  (2.0)  as  a  graphical  way  to  specify  and  construct  the  artifacts 
necessary  for  building  a  software  system. 

1.  Use  Case 

Use  cases  are  the  generally  accepted,  standardized  method  used  to  represent  and 
present  system  functionality.  The  use  case  describes  the  system’s  expected  usage  in  a 
textual  format  along  with  the  diagrams.  A  use  case  describes  a  sequence  of  actions  that 
provide  a  measurable  value  for  the  relationships  among  actors  in  a  system  and  are  best 
expressed  as  an  expected  use  of  a  system.  Use  cases  are  organized  using  a  UML  schema. 
A  use  case  template  provides  a  well-defined  method  of  outlining  a  system  use  case  and 
can  be  used  as  a  good  basis  for  its  development.  Table  1  depicts  the  use  case  template 
used  in  this  dissertation. 


Table  1.  Use  Case  Template 


Item 

Contents 

Use  Case  Name 

Assign  a  name  to  the  Use  Case. 

Actors 

Name  of  the  actor(s)  who  participates  in  the  Use  Case. 

Brief  Description 

Summarize  the  Use  Case  scenario. 

Flow  of  Events 

Describe  sequentially  the  basic  behavior  following  this  Use 

Case. 

Alternative  Flow  of 
Events 

For  Use  Cases,  this  occupies  a  partial  event  in  the  basic  flow. 
Alternative  flow  is  also  meaningful,  although  in  a  lesser  way. 
The  alternative  path  is  considered  when  the  basic  cases  are 
interrupted  by  a  condition  in  the  system  or  a  Misuse  Case. 

Precondition 

Describe  conditions  and  backgrounds  that  are  satisfied  before 
entering  the  Use  Cases  and  can  be  ensured  by  the  system  itself. 

Post  Condition 

Describe  conditions  that  hold  after  the  Use  Case  has  executed 
on  the  system  itself 
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2. 


Misuse  Case 


A  Misuse  Case  represents  the  actions  that  a  mal-actor  should  be  prevented  from 
performing  with  respect  to  the  system.  The  relationships  between  Use  and  Misuse  Cases 
can  be  expressed  using  relations  such  as  «extend»,  «include»,  «prevent»,  and 
«mitigate» .  Some  instance  of  misuse  can  include  or  extend  a  Use  Case  to  achieve 
undesirable  system  behavior,  while  other  Misuse  Cases  show  actions  preventing  the  Use 
Cases.  The  Misuse  Case  template  contains  many  of  the  same  entities  as  that  for  Use 
Cases  and  includes  a  narrative-based  textual  schema,  as  well  as  a  Misuse  Case  diagram. 
The  templates  are  not  unique,  as  there  are  many  variations  among  recommended 
templates  for  Use  Cases  and  Misuse  Cases,  but  to  be  able  to  specify  misuse  requires 
examining  not  only  a  basic  flow,  like  a  Use  Case,  but  also  a  secondary  flow.  In  other 
words,  we  need  to  examine  the  Use  Case  fields  and  then  consider  which  of  these  would 
also  be  relevant  for  a  Misuse  Case  template.  Fields  such  as  name,  actors,  description,  and 
flow  of  events,  are  relevant  to  both  Use  Cases  and  Misuse  Cases.  However,  misuse  cases 
assume  exceptional  events  that  go  against  standard  behaviors  of  use  cases  to  exploit  some 
element  of  the  system.  This  requires  additional  fields  to  capture  the  threat  involved,  the 
system  vulnerability,  and  the  risk  of  exploitation.  Table  2  contains  the  template  used  in 
this  dissertation  for  Misuse  Cases. 
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Table  2.  Misuse  Case  Template 


Item 

Contents 

Misuse  Case  Name 

Assign  a  name  to  the  Misuse  Case. 

Actors 

Name  of  the  mal-actor  who  provokes  the  misuse  ease. 

Brief  Description 

Summarize  a  Misuse  Case  seenario. 

Flow  of  Events 

Deseribe  sequentially  the  basic  behavior  following  this  misuse  case. 

Alternative  Flow  of 
Events 

For  Misuse  Cases,  this  occupies  a  partial  event  in  the  basic  flow. 
Alternative  flow  is  also  meaningful,  although  in  a  lesser  way.  The 
alternative  path  is  considered  when  the  basic  Misuse  Cases  are 
interrupted  by  a  Use  Case. 

Precondition 

Describe  conditions  and  backgrounds  that  are  satisfied  by  triggering 
the  Misuse  Cases  and  can  be  ensured  by  the  system  itself 

Assumption 

Describe  conditions  that  must  be  true,  but  which  cannot  be 
guaranteed  by  the  system  itself 

Exploited 

Vulnerability 

Describe  the  vulnerability  that  exists  in  the  system  that  is  being 
exploited  by  the  Misuse  Case. 

Worst  Case  Threat 

Describe  the  outcome  if  the  misuse  succeeds.  If  the  Misuse  Case  has 
alternative  paths,  often  this  condition  will  be  or  contain  a  disjunction 
to  describe  slight  variations  in  outcome. 

Capture  Guarantee 

Describe  the  outcome  guaranteed  by  whatever  prevention  path  is 
followed.  If  no  prevention  path  is  followed,  one  might  alternatively 
formulate  a  wanted  prevention  guarantee,  expressing  what  one  would 
want  the  system  to  achieve  with  respect  to  the  attempted  misuse,  but 
without  stating  how. 

Related  Business 
Rules 

Describe  what  business  rules  are  violated. 

Potential  Misuse 
Profile 

Some  kinds  of  misuse  are  most  likely  to  be  performed  by  intent 
whereas  other  may  happen  accidentally,  for  example.  Some  require 
insiders  or  people  with  enormous  technical  skill,  while  others  do  not. 

Stakeholders  and 
Threat 

This  field  lists  the  various  stakeholders  and  their  motivations.  For 
misuse  cases,  this  slot  is  even  more  important.  In  this  field,  risks  can 
simply  be  described  textually. 

Scope 

This  field  represents  the  scope  of  modeling. 
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3.  Security  Use  Case 

The  combination  of  use  and  misuse  necessitates  a  Security  Use  Case  to  mitigate, 
detect,  or  prevent  an  associated  misuse.  This  Security  Use  Case  represents  the  system’s 
method  of  dealing  with  the  vulnerabilities  the  Misuse  Case  exploited  within  the  system. 
The  template  used  in  this  dissertation  for  Security  Use  Cases  will  model  that  of  the  Use 
Case  that  was  shown  in  Table  1. 

D.  SERVICE-ORIENTED  ARCHITECTURE 

A  service-oriented  architecture  (SOA)  is  an  architecture  that  supports  the 
discovery,  binding,  and  execution  of  resources  (a.k.a.,  services)  or  the  composition  of 
resources  via  a  network  [27,  28].  Web  Services  (WS)  standards  are  available  for 
implementing  systems. 

In  this  section,  we  summarize  [27]  and  introduce  definitions  of  SOA,  SOA 
characteristics,  and  service-orientation  principles. 

In  [27],  Contemporary  SOA  is  defined  as  follows: 


Contemporary  SOA  represents  an  open,  agile,  extensible,  federated, 
composable  architecture  comprised  of  autonomous,  QoS-capable,  vendor 
diverse,  interoperable,  discoverable,  and  potentially  reusable  services, 
implemented  as  Web  services. 

SOA  can  establish  an  abstraction  of  business  logic  and  technology, 
resulting  in  loose  coupling  between  these  domains. 

SOA  is  an  evolution  of  past  platforms,  preserving  successful 
characteristics  of  traditional  architectures,  and  bringing  with  it  distinct 
principles  that  foster  service-orientation  in  support  of  a  service  oriented 
enterprise. 

SOA  is  ideally  standardized  throughout  an  enterprise,  but  achieving  this 
state  requires  a  planned  transition  and  support  of  a  still  evolving 
technology  set. 
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The  preceding  definition  on  contemporary  SOA  is  based  on  separation  of 
concerns  [27].  Services  encapsulate  logic  for  solving  the  decomposed  individual  concerns 
of  existing  complex  problems. 

There  are  three  basic  components  of  the  SOA  architecture:  services,  description, 
and  messaging.  The  service  is  the  executable  code;  the  (service)  description  contains  the 
name  of  the  service,  location  of  the  service,  and  the  input  and  output  exchange 
requirements;  and  messages  are  independent  units  of  communication  that  the  services  use 
to  communicate  [27].  An  adaptation  from  [27]  shows  these  components  in  Figure  5. 
These  components  could  also  describe  a  distributed  architecture;  yet  SOA  is  highlighted 
by  how  each  of  these  components  is  designed;  using  service-orientation  principles. 


Services 


How  should 
services  be 
designed? 


How  should  the 
relationship  between 
services  be  defined? 


Mes.sa2e.s 


How  should  service 
descriptions  be 
designed? 


De.snipHoii 


How  should 
messages  be 
designed? 


Figure  5.  Basic  SOA  Components  and  Design  Relation,  from  [27] 


Service-orientation  principles  are  “a  set  of  principles  most  associated  with 
service-orientation”  [27].  These  principles  are  applied  to  the  development  of  the  basic 
SOA  components.  The  eight  principles  are  listed  in  Table  3. 
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Table  3.  Service-Orientation  Guiding  Principles,  from  [27] 


Service-orientation 

principle 

Brief  description 

Reusability 

Services  are  designed  to  support  immediate  and 
potential  reuse 

Service  contract 

Services  are  designed  with  formal  contracts 
which  describe  the  service  and  expose  a  services 
data  sharing  requirements 

Loose  coupling 

Services  are  designed  to  relate  without 
dependencies  on  other  services 

Abstraction 

Service  contracts  are  the  only  visible  entity  of  a 
service.  The  actual  service  is  of  no  concern  to  the 

user 

Service-orientation 

principle 

Brief  description 

Composability 

Services  can  make  up  other  services 

Autonomy 

Services  are  designed  to  be  independent,  self- 
governing  within  an  explicit  boundary 

Statelessness 

Services  are  designed  so  as  not  to  manage  state 
information 

Discoverability 

Services  are  designed  to  be  discovered  for  use; 
they  expose  their  formal  contract  for  anyone  to 
use 

One  additional  piece  of  the  primitive  SOA  definition  is  what  [27]  calls  the 
implementation  platform.  This  is  where  Web  Services  are  used  to  integrate  the 
components  and  provide  our  service-oriented  solution. 

Contemporary  SOA  is  based  on  primitive  SOA,  but  differs  in  that  Primitive  SOA 
represents  what  can  and  is  being  done  with  existing  Web  services  technology  rather  than 
what  is  being  done  with  current  Web  Services  technology  and  what  can  be  done  in  the 
future  with  extensions  to  the  current  WS.  Table  4  lists  the  common  characteristics  of 
Contemporary  SOA,  as  described  in  [27]. 
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Table  4.  Common  Characteristics  of  Contemporary  SOA,  after  [27] 


Common  Characteristics  of  Contemporary  SOA 

Contemporary  SOA  is  at  the  core  of  the  service-oriented  computing  platform 

Contemporary  SOA  increases  Quality  of  Services  (QoS) 

Contemporary  SOA  is  fundamentally  autonomous 

Contemporary  SOA  is  based  on  open  standards 

Contemporary  SOA  supports  vendor  diversity 

Contemporary  SOA  fosters  intrinsic  interoperability 

Contemporary  SOA  promotes  discovery 

Contemporary  SOA  promotes  federation 

Contemporary  SOA  promotes  architectural  composability 

Contemporary  SOA  fosters  inherent  reusability 

Contemporary  SOA  emphasizes  extensibility 

Contemporary  SOA  supports  a  service-oriented  business  modeling  paradigm 

Contemporary  SOA  implements  layers  of  abstraction 

Contemporary  SOA  promotes  loose  coupling  throughout  the  enterprise 

Contemporary  SOA  promotes  organizational  agility 

Contemporary  SOA  is  a  building  block 

Contemporary  SOA  is  an  evolution 

Contemporary  SOA  is  still  maturing 

Contemporary  SOA  is  an  achievable  ideal 

A  full  description  of  each  characteristic  listed  in  Table  4  can  be  found  in  [27], 
This  list  is  used  to  show  that  Contemporary  SOA  is  neither  merely  Web  Services  and 
service-oriented  principles,  nor  is  it  a  commercial  off-the-shelf  (COTS)  product  that 
provides  a  guaranteed  solution.  It  is  a  highly  adaptable  reference  point  to  begin  creation 
of  a  flexible  system  architecture  that  relies  on  services.  The  extensible  Markup  Language 
(XML)  is  the  basis  for  much  of  the  web  services.  XML  Schemas  are  used  to  describe 
rules  for  an  XML  document  to  conform  to  and  to  provide  validity  through  the  use  of  an 
XML  Schema  Definition  (XSD).  The  XSD  is  an  instance  defining  a  document  by 
constraints  on  elements,  attributes,  relationships,  and  data. 

Web  Services  Description  Language  (WSDL),  SOAP  (formerly  Simple  Object 
Access  Protocol),  and  Universal  Description,  Discovery,  and  Integration  (UDDI)  are 
commonly  referred  to  as  the  first  generation  Web  services  standards  [27,  28].  Each  of 
these  standards  represents  a  concern  for  the  development  of  a  Web  service.  WSDL  is  a 
standard  used  to  develop  an  XML-based  document  that  contains,  at  a  minimum,  the 
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service  name,  location,  and  input  and  output  requirements.  This  is  the  contract  for  a 
service  and  defines  services  as  ports  or  network  endpoints.  The  WSDL  document  is  a 
user’s  interface  to  an  actual  service  and  the  information  in  a  WSDL  resides  in  a  UDDI 
registry  so  that  the  service  can  be  discovered.  UDDI  is  a  specification  used  to  design  an 
XML-based  registry  service  for  Web  services.  The  information  contained  in  a  WSDL  has 
a  standard  format,  as  outlined  in  the  OASIS  UDDI  specification,  and  mapped  to  a  UDDI 
data  model.  The  UDDI  is  open  to  SOAP  messaging  queries,  which  allows  for  any 
registered  service  to  be  found  and  also  describes  the  protocols  and  messaging  formats 
necessary  to  communicate  with  the  service  in  question.  The  communications  framework 
is  further  described  by  the  SOAP  standard.  SOAP  is  an  XML-based  language  and  a 
platform-independent  communications  protocol  for  exchanging  messages  between 
services  over  a  network.  SOAP  is  a  stateless,  one-way  message  exchange  that  is  typically 
transported  via  HTTP/HTTPS  or  SMTP.  A  graphical  representation  of  the  core  standards 
and  how  they  relate  is  provided  in  Figure  6. 


UDDI 


services 


is  accessed 
using 


SOAP 


Figure  6.  Basic  SOA  with  Core  Web  Service  Standards,  from  [27] 
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Additionally,  Web  Services  Business  Process  Execution  Language  (WS-BPEL) 
provides  a  means  for  specifying  how  to  integrate  elements.  It  is  also  used  to  import  and 
export  functionality  by  WS  interfaces.  This  is  intended  to  model  abstract  and  executable 
processes  where  BPEL  can  be  used  as  an  orchestration  language,  so  that  the  executable 
process  and  message  exchange  are  controlled  (central  control  of  a  distributed  system’s 
behavior).  This  is  different  than  choreography,  where  protocols  of  interaction  and  legal 
sequences  of  messages  for  interoperability  are  specified  (a  distributed  system  without 
centralized  control). 

E.  INFORMATION  BROKER 

The  Information  Broker  (IB)  is  a  key  service  in  a  SOA  implementation  of  a  MLS 
system.  It  enforces  access  control  policy  and  provides  for  the  orchestration  of  security 
services.  Turner  et  al.  discuss,  in  [44],  the  creation  and  application  of  an  IB  in  SOA-based 
system  in  a  healthcare  domain.  This  is  a  single  security  level,  but  does  encompass 
multiple  domains  and  distributed  data  repositories,  similar  to  this  research.  Turner  et  al. 
use  XACL  as  the  specification  language  for  the  IB  [44].  The  IB  can  be  likened  to  an 
Enterprise  Service  Bus  (ESB)  that  provides  messaging  between  the  components  or 
business  logic  [29].  The  ESB,  however,  is  not  designed  for  a  true  SOA  system  to  provide 
a  service,  but  rather  to  interface  via  messaging  between  two  dissimilar  services  or 
otherwise  incompatible  components.  In  contrast,  the  IB  serves  as  the  orchestration 
mechanism  at  the  heart  of  the  trusted  computing  base  (TCB)  and  is  replicated  for  each 
confidentiality  level. 

F.  MULTILEVEL  SECURITY 

Multilevel  security  is  used  to  describe  systems  that  can  operate  at  varying  security 
levels  without  the  need  for  separate  hardware  to  provide  the  access  to  a  secondary 
classification  level  of  information.  Two  major  categories  of  implementation  exist  for 
these  systems;  those  utilizing  a  separation  kernel  and  those  without.  Rushby  offers  that 
the  role  of  a  security  kernel  is  to  separate  environments  on  a  single  processor  as  if  they 
were  running  on  physically  separate  machines  [30].  Typically,  it  was  the  “one  component 
that  partitioned  many  kinds  of  resources  (complex  implementation),  and  either  enforced  a 
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single  operational  security  property  (too  rigid  to  be  useful)  or  several  (too  complicated  to 
be  credible)”  [31].  Several  foundational  elements  are  required  to  include:  the  ability  to 
prove  no  information  flow  channels  exist  between  domains,  non-bypassable, 
tamperproof,  and  being  small  enough  to  test  and  analyze  completely. 

1.  Separation  Kernel  Based 

Multiple  Independent  Levels  of  Security  (MILS)  is  a  high-assurance  security 
architecture  based  on  processing  separation  and  controlled  information  flow.  MILS 
allows  for  independent  evaluation  of  security  components  and  trusted  composition.  Much 
work  has  been  done  with  MILS  by  VanFleet  [8]  as  an  extension  of  the  design  of  secure 
systems  from  Rushby  [30].  This  is  fundamentally  different  than  the  SOA  based 
implementation.  MILS  focuses  on  multiple  levels  of  security  on  a  single  system  and  not 
via  distributed  computing.  MILS  systems  could  serve  as  endpoints  offering  multiple 
sensitivity  levels  from  a  single  source  to  augment  the  approach  discussed  in  this  research. 

While  there  is  a  lack — ^primarily  due  to  cost — of  proprietary  systems  that  have 
been  built,  certified  and  accredited,  the  door  has  opened  for  the  use  of  non-developmental 
items.  Boeing  is  now  using  the  WindRiver  VxWorks  MILS  Platform  2.0  separation 
kernel  for  its  embedded  real-time  systems.  Additional  and  comparable  software 
separation  kernels  to  support  MILS  are  offered  by  Green  Hills  (Integrity  178B)  [32],  and 
LynuxWorks  (LynxSecure)  [33].  These  efforts  have  resulted  in  EAL6+  certified  systems 
with  additional  examples  from  Rockwell  Collins’  AMP7,  and  Boeing’s  Secure  Network 
Sever  that  with  additional  integration  and  effort  could  result  in  a  full  implementation. 
Cisco,  Microsoft,  EMC  and  Deem  partnered  to  create  the  Secure  Information  Sharing 
Architecture  (SISA).  SISA  utilizes  commercially  available  products  to  provide 
information  sharing  and  separation  controls  at  the  PL3  (Medium  Assurance)  level  [34]. 
SISA  does  not  support  SOA  and  is  not  a  high  assurance  solution. 

2.  Non-separation  Kernel  Based 

BAE  Systems’  STOP  OS  is  an  example  of  a  non-separation  kernel  based 

implementation  for  MLS  [35].  BAE  integrates  the  STOP  OS  with  their  Next  Generation 

XTS  Guard  into  a  Secure  Application  Platform  as  the  basis  for  specification  and 
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enforcement  of  security  policy  in  MLS,  cross-domain  environments  [36-38].  This 
approach  is  heavily  reliant  on  the  use  of  the  XTS  Guard  and  the  security  controls 
enforced  by  the  operating  system. 

The  information  broker  approach  via  SOA  that  is  described  in  this  research  is 
based  on  the  services  and  the  distributed  environment  inherent  with  the  model.  While  the 
underlying  individual  operating  system  is  independent  of  the  information  broker’s 
mission,  the  STOP  OS  is  designed  as  a  general  purpose  OS  to  be  run  on  individual 
systems  to  maintain  data  separation.  The  Radiant  Alloy  model  provides  for  the  TLS  and 
IB  to  make  the  separation  decisions  prior  to  the  information  arriving  at  an  individual 
system.  This  is  an  OS  that  could  be  used  in  conjunction  with  Radiant  Alloy  and  the  IB, 
but  could  not  replace  the  TCB  and  functionality  of  the  IB  itself  that  we  are  specifying 
policy  rules  to  implement.  The  functions  of  the  operating  system  to  control  access  to  the 
hardware  are  not  an  implementation  goal  of  Radiant  Alloy,  where  any  network  capable 
device  is  inclusive  of  the  intended  platforms  for  use. 

McCullough,  in  [41],  describes  a  security  property  for  MLS  systems  called 
restrictiveness.  This  property  refers  to  the  ability  of  a  user  to  infer  sensitive  information 
from  the  system  within  the  scope  of  the  security  policy.  Additionally,  McCullough  offers 
this  restrictiveness  as  holding  with  a  hook-up  or  composable  property  when  combining 
secure  systems  to  a  single  composite  system. 

Goguen  and  Meseguer,  in  [42],  present  verification  of  an  MLS  keying  on  security 
policy  satisfaction  for  a  specified  security  model.  Their  approach  analyzes  non¬ 
interference  of  information  flows  for  the  security  policy  and  the  high-level  specification 
to  verify  the  security  of  a  system.  This  work  did  not  encompass  inference  or  information 
aggregation  creating  security  policy  violations  as  we  do  in  this  dissertation. 

Trusted  Solaris  provides  an  implementation  of  RBAC  and  supports  MLS.  Trusted 
Solaris,  however,  is  designed  for  the  operating  system  processes  only  and  not  for  the 
movement  and  dissemination  of  data  in  a  distributed  or  SOA  system. 

Osborn,  Sandhu  and  Munawer  in  [39],  attempted  to  show  the  inclusion  of  MLS 
policy  (BLP)  using  RBAC  roles.  They  developed  models  for  using  RBAC  to  encompass 
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both  DAC  and  MAC  policies  via  roles.  The  use  of  a  lattice-based  access  eontrol  model 
and  the  generality  of  the  RBAC  model  allows  for  the  simulation  of  these  other  models. 
Despite  RBAC  being  more  expressive  than  BLP  and  allowing  the  limited  modeling  of 
MLS  within  a  role,  the  implementation  in  RBAC  relied  on  a  single  administrator  role. 
This  laeks  the  true  separation  of  duties  and  responsibility  necessary  for  a  MLS  system. 
This  would  involve  a  violation  of  the  *-property,  and  Simple  Security  property.  RBAC 
was  defined  in  [40],  then  expanded  in  [41]  before  its  aceeptanee  by  The  National  Institute 
of  Standards  and  Technology  (NIST)  in  [42].  RBAC  has  also  been  shown  in  [25,  43-48] 
to  provide  a  sound  platform  to  develop  assuranees  of  access  eontrol  using  administrative 
roles  and  varying  aeeess  control  mechanisms.  Additionally,  Kuhn  provided  a  coneept  to 
provide  RBAC  on  an  existing  MLS  system  in  [43]. 

Freeman,  Neely,  and  Heekard  [14]  offer  a  way  to  map  security  policy  into  a 
model  based  on  the  seeurity  requirements  and  the  system  arehiteeture.  Their  Boundary 
Flow  Modeling  (BFM)  approach  helps  to  model  the  security  policy  with  regard  to  the 
system  arehiteeture  it  will  operate  in,  rather  than  trying  to  enforce  a  generic  policy  on  an 
incompatible  domain.  It  also  allows  for  mathematieal  formalization  of  the  poliey  model 
as  an  additional  problem  with  a  distributed  system  is  that  in  general  they  are  non- 
deterministie,  sinee  separate  processors  in  the  system  execute  state  ehanges  in  an  order 
that  is  not  predietable  relative  to  the  others  in  the  system.  But,  the  seeurity  requirements 
must  still  be  adhered  to.  Boundary  flow  modeling  addresses  this  by  defining  relationships 
rather  than  funetions,  between  inputs  and  outputs  where  these  relationships  ean  be 
modeled  mathematically  as  a  relation  and  can  account  for  nondeterministic  behavior  in 
the  system  [14].  Their  BFM  method  is  designed  to  aid  in  the  development  proeess  and 
does  not  provide  an  implementation  method  as  addressed  in  this  research. 

3.  Other  Multilevel  Security  Work 

Multilevel  security  is  a  common  desire  with  information  repositories.  The  Sea 
View  seeurity  model  [60]  addresses  the  concept  of  multiple  levels  enforced  by  a 
referenee  monitor  and  the  extension  of  individual  data  classifieations  in  the  database  for 
enforeement  and  creates  multiple  database  servers  for  every  level  the  user  dominates. 
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This  approach  does  not  allow  for  the  capability  of  connecting  to  multiple  disparate  data 
stores  outside  of  a  relational  database,  nor  does  it  account  for  the  prioritization  and 
emergence  of  additional  data  flows  that  must  be  accounted  for  within  current  operational 
systems. 

G.  GUARDS 

Guards  are  mechanisms  designed  to  limit  the  exchange  of  information  between 
systems  [49]  and  utilize  any  number  of  inputs  to  determine  the  release  or  modification  of 
the  information  in  question.  This  is  a  critical  element  of  any  cross-domain  effort  and  its 
implementation  is  usually  the  hallmark  of  the  system  architecture  itself  There  is  much 
prior  work  related  to  differing  guard  implementations,  yet  none  of  these  allow  for  the 
same  level  of  expressiveness  and  granularity  as  provided  through  the  integration  of 
RuleML  and  the  Information  Broker  described  in  this  research. 

The  Information  Support  Server  Environment  (ISSE)  Guard  from  the  Air  Force 
Research  Laboratory  (AFRL)  allows  for  bi-directional  email  messaging,  imagery,  and 
Microsoft  Office  fde  transfer  between  interconnected  domains  [50].  This  guard  supports 
a  single  high-side  system  with  up  to  eight  low-side  systems,  but  it  does  not  provide  a 
means  for  the  system  to  ensure  that  labels  a  user  associates  with  information  provided  to 
the  system  are  consistent  with  the  sensitivity  levels  that  the  user  is  allowed  to  access. 
This  is  not  as  scalable  as  the  SOA-based  implementation  of  Radiant  Alloy  and  the  guard 
characteristics  are  defined  for  a  limited  scope  of  transfer  [51].  The  National  Security 
Agency  (NSA)  and  AFRL  are  jointly  working  to  integrate  XML  capabilities  into  the 
ISSE  to  allow  for  transfer  between  domains  and  provide  this  via  web  services.  This  is 
different  than  the  use  of  RuleML  with  an  information  broker  and  is  content  based  rather 
than  configuration  based.  The  ability  and  the  need  to  transfer  data  across  the  domains 
using  the  ISSE,  as  well  as  future  expansion  to  support  new  XML  capabilities,  is  the  goal. 

The  Defense  Messaging  System  (DMS)  is  a  follow-on  cross-domain  messaging 
service  created  from  the  legacy  Defense  Switched  Network  (DSN)  AUTODIN  System 
based  on  labels.  DMS  provides  two  categories  of  service:  High  Grade  Service  (HGS) 
uses  modified  commercial  email  clients  and  a  FORTEZZA  token-based  Class  4  Public 
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Key  Infrastructure  (PKI)  certificate,  while  Medium  Grade  Service  (MGS)  uses 
commercial  email  clients  with  a  Class  3  PKI  certificate  [52],  The  DMS  supports  four 
DMS  security  domains:  Unclassified  (U),  Secret  (S),  Top  Secret-Collateral  (TS)  and  Top 
Secret/Sensitive  Compartmented  Information  (SCI);  according  to  the  transport  network. 
DMS  utilizes  a  High  Assurance  Guard  (HAG)  for  cross-domain  exchange  of  message 
traffic,  which  is  different  than  the  use  of  an  information  broker  as  the  central  control 
element  between  data  repositories.  The  idea  of  disparate  classifications  using  a  message 
system  is  limited  in  the  ability  of  the  guard  to  check  the  content  and  parse  the  messages. 

The  Navy  Research  Laboratory  (NRL)  modified  its  original  Pump  to  a  Network 
Pump  to  create  a  high  assurance  guard  that  supports  cross-domain  messaging  [53].  This 
allows  transfer  from  low  to  high  and  prevents  the  downward  flow,  but  also  provides  an 
acknowledgement  indication  of  the  transfer  back  to  the  low-side.  This  approach  also 
relies  on  modifying  the  timings  of  the  response  messaging  in  order  to  mitigate  the  use  of 
transfer  responses  as  a  covert  channel.  This  approach  has  a  few  drawbacks  compared 
with  the  use  of  an  Information  Broker  and  specification  of  policy  using  RuleML. 
Although  offering  limited  support  of  information  sharing  among  disparate  users,  the 
types  of  transfer  are  limited  while  the  use  of  RuleML  specifying  a  security  policy  allows 
for  greater  expressivity  and  can  also  be  constructed  to  eliminate  the  inference  ability  of  a 
lower  classification  user.  This  also  allows  for  multi-level  classification  of  information 
and  thus,  a  different  view  related  to  similar  objects  between  users  (e.g.,  a  ship’s  detailed 
track  history).  The  NRL  Pump  also  is  intended  as  a  part  of  a  larger  collection  of  networks 
rather  than  as  an  information  destination  connected  via  a  service-oriented  architecture 
and  rapidly  scalable  via  a  replication  of  IB  service  and  is  only  a  one-way  guard  as 
opposed  to  bi-directional. 

The  Monterey  Security  Architecture  (MYSEA)  is  a  related  concept  to  allow  for 
distributed  information  sharing  for  MLS  [54].  However,  the  MYSEA  is  an 
implementation  of  the  Trusted  Computing  Base  (TCB),  and  would  serve  as  a  viable 
alternative  to  Radiant  Alloy  as  used  in  this  research.  The  MYSEA  does  not  implement  a 
defined  ruleset  supporting  policy,  but  rather  the  environment  in  which  to  create  the 
enforcement  and  authorization  mechanisms  for  the  multilevel  security  policy. 
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BAE  Systems  uses  the  Next  Generation  XTS  Guard  as  an  integral  pieee  of  their 
Secure  Application  Platform,  along  with  the  STOP  OS  described  previously  [36-38].  The 
XTS  Guard  is  designed  for  use  as  a  gateway  for  desktop,  server,  or  network 
environments.  It  is  designed  to  separate  data  from  varying  security  levels  based  on  label 
and  sensitivity,  yet  it  does  not  allow  for  the  openly  configurable  rulesets  and  must  rely  on 
proprietary  hardware  and  software  elements  to  provide  its  services. 

H.  FIREWALL  AND  IPS  LANGUAGES 

Current  enterprise-level  firewalls  and  Intrusion  Protection  Systems  (IPS)  have 
reached  a  level  of  sophistication  that  was  not  available  in  prior  generations  of  devices. 
The  prior  reliance  on  port  number,  protocol,  and  IP  address  filtering  have  been 
superseded  by  a  more  dynamic  ability  to  restrict  or  block  traffic  based  on  triggers  and 
performance  thresholds  established  for  the  device.  While  the  functionality  and  concept  of 
creating  and  running  rules  to  support  filtering  and  blocking  of  network  traffic  by  a 
firewall  and  intrusion  protection  system  (IPS)  are  similar,  the  firewall  and  IPS  rules  are 
much  different  than  the  use  of  RuIeML  in  this  research.  Typical  configuration  of  these 
network  appliances  is  via  a  graphical  user  interface  (GUI)  and  is  proprietary  to  each 
respective  vendor.  However,  these  are  all  similar  in  the  underlying  rule  generation,  which 
is  very  simple  logic.  This  allows  for  the  devices  to  operate  at  very  high  data  rates  to 
perform  the  specific  function  of  filtering  content  in  the  network,  but  does  not  permit 
complex  logic  such  as  a  filtering  of  a  suspicious  domain  based  on  recent  network  traffic 
patterns.  These  firewall  rules  are  executed  in  a  simple  beginning  to  end  list,  where  the 
first  rule  is  evaluated  and  if  it  is  not  triggered  the  execution  continues  to  the  next  rule  in 
sequence  [55].  As  soon  as  a  rule  is  triggered,  the  remaining  rules  are  ignored  and  the 
initial  decision  is  upheld  for  that  particular  rule.  This  prevents  the  ability  to  ensure  rule 
consistency  throughout  the  rule  list  and  is  one  of  the  primary  concerns,  from  both 
network  appliance  vendors  and  enterprise  clients,  as  rulesets  for  these  devices  become 
ever  larger  to  account  for  growing  enterprise  needs  and  emerging  threats. 

Multiple  vendors  offer  network  appliance  solutions,  such  as  firewalls  (FW), 
intrusion  protection  systems  (IPS),  and  intrusion  detection  systems  (IDS).  Each  of  these 
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has  a  variation  with  its  own  corporate  branding  and  a  different  user  interface,  yet  the 
underlying  structure  and  exeeution  models  are  similar.  Cisco  Systems  Ine.  offers  the  ASA 
5500  Adaptive  Seeurity  Appliance  [56]  line  of  firewalls  as  the  top-tier  of  their  efforts. 
Cheek  Point  Software  Teehnologies  Ltd.  offers  the  61000  Security  System  [57].  MeAfee 
Firewall  Enterprise  [58]  is  the  top  offering  of  McAfee  and  is  branded  as  a  next-generation 
device.  While  each  of  these  vendors  touts  advaneed  seeurity  and  adaptive  measures  for 
filtering  and  content  eontrol,  the  underlying  operation  is  still  reliant  on  a  simple  logic  that 
lacks  complexity  and  expressiveness.  Overeoming  these  weaknesses,  RuleML  in  our 
example  allows  for  the  use  of  ehaining  rules  and  ean  be  cheeked  for  eonsistency  with  the 
ruleset.  The  ability  to  add  a  eomplex  rule  is  also  evident  in  RuleML.  However,  while  this 
fiinetions  well  for  a  speeific  enterprise  device,  it  is  not  expressive  enough  and  only  eovers 
a  single  domain  when  eompared  to  the  use  of  RuleML  and  an  Information  Broker  as  we 
deseribe 

In  line  with  the  network  applianee  is  the  funetionality  offered  by  the  IPS,  and  how 
it  processes  network  flow.  One  of  the  most  widely  used  of  these,  offering  both  an  open 
source  rule  engine  and  rule  language,  is  Snort.  Snort  allows  you  to  extend  its  predefined 
syntax  and  rules  to  meet  the  needs  of  the  network.  This  is  a  common  application  within  a 
corporate  enterprise  network  and  is  used  on  many  different  hardware  applianees  to 
support  intrusion  detection  and  prevention.  A  Snort  rule  ean  be  broken  down  into  two 
basie  parts,  the  rule  header  and  options  for  the  rule.  The  rule  header  eontains  the  aetion  to 
perform,  the  protocol  that  the  rule  applies  to,  and  the  souree  and  destination  addresses 
and  ports.  The  rule  options  allow  you  to  ereate  a  deseriptive  message  to  associate  with  the 
rule,  as  well  as  eheck  a  variety  of  other  paeket  attributes  by  making  use  of  Snort’s 
extensive  library  of  plug-ins.  The  generie  Snort  rule  is:  action  protocol  src_ip  src _port 
direction  dst_ip  dst _port  (options)  [59].  This  is  again  simple  logic,  not  allowing  for  rule 
chaining  and  lacking  in  expression  for  more  eomplex  filtering.  When  a  packet  eomes  in, 
its  source  and  destination  IP  addresses  and  ports  are  eompared  to  the  rules  in  the  ruleset. 
If  any  of  them  is  applieable  to  the  packet,  then  the  options  are  eompared  to  the  paeket.  If 
all  of  these  eomparisons  return  a  mateh,  then  the  speeified  aetion  is  taken.  All  other  rules 
in  the  set  are  exeluded  from  eonsideration  after  a  single  rule  is  triggered.  As  we  ean  see, 
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the  underlying  basis  is  simple  and  designed  for  speed  of  exeeution  for  high-flow  network 
entry  points  where  throughput  is  paramount.  Yet,  these  rules  and  the  language  used  to 
support  them  are  not  suffieient  to  meet  the  needs  of  our  eross-domain  information  broker. 

I.  XACML 

extensible  Access  Control  Markup  Language  (XACML)  is  an  OASIS  standard. 
XACML  is  the  access  controller  of  the  Web  Services  languages  and  the  current  reference 
implementation  has  a  single  policy  decision  point  (PDF)  and  a  policy  enforcement  point 
(PEP). 
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The  current  XACML  specification  has  three  main  entities  as  shown  in  Figure  7. 
The  main  components  are: 

1 .  Policy  Administration  Point  (PAP):  Entity  that  creates  policies  or  policy 
sets. 

2.  Policy  Decision  Point  (PDP):  Entity  that  evaluates  applicable  policy  and 
renders  an  authorization  decision.  The  answer  given  by  the  PDP  is  one  of 
(1)  permit,  (2)  deny,  (3)  insufficient  information  to  decide  or  (4)  error, 
occurred  in  the  execution. 

3.  Policy  Enforcement  Point  (PEP):  Entity  that  performs  access  control  by 
enforcing  authorization  decisions. 

Figure  7  also  shows  the  dataflow  of  the  XACML  reference  implementation.  First, 
the  PAP  creates  a  policy.  At  request  time,  an  access  request  arrives  at  the  PEP  (flow  2), 
and  is  sent  to  the  context  handler  (flow  3).  The  context  handler  determines  resources  to 
be  accessed  and  attributes  of  the  requester,  resource  and  the  environment,  collects  all 
required  attributes  and  forwards  them  to  the  PDP  (flows  4  through  8).  The  PDP  then 
acquires  the  policy  from  PAP  (flow  1),  evaluates  the  relevant  policy  and  relays  the 
decision  (flows  9,  10)  to  the  PEP  through  the  context  handler,  which  then  enforces  the 
authorization  decision  [60]. 

The  policy  syntax  (XML)  includes  language  constructs  to  identify  the  resource, 
the  action  (to  be  performed  on  the  resource),  the  subject,  and  constraints  on  the  access.  In 
XACML  parlance,  this  collection  of  entities  is  called  a  target.  The  request  syntax  (XML) 
identifies  the  resource,  the  action,  the  subject.  The  decision  engine  (PDP)  matches  the 
incoming  request  to  available  policies  to  discover  all  applicable  policies.  If  more  than  one 
policy  is  applicable,  then  the  PDP  uses  a  policy-combination  algorithm  [61]  to  determine 
the  evaluation  result.  In  essence,  the  combination  algorithm  states  how  to  combine  the 
result  of  each  applicable  policy.  For  example,  it  can  state  that  the  final  result  is  the 
conjunction/disjunction  of  the  individual  results,  or  the  first-applicable  policy  evaluation 
result  is  the  final  result  [60]. 
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J.  RULEML 

Rule  Markup  Language  (RuleML)  specifies  Prolog-like  rules  that  use  an  XML- 
like  syntax,  and  consequently  are  valuable  with  SOA.  RuleML  was  initially  developed  by 
the  Rule  Markup  Initiative  to  express  rules  in  XML  for  various  tasks.  The  semantic 
foundation  of  RuleML  is  based  on  datalog,  which  combines  SQL  and  Prolog,  and  can  be 
considered  as  a  subset  of  logic  programming  [62],  RuleML  serves  the  Resource 
Description  Framework  (RDF)  as  a  canonical  Web  language.  While  RDF  is  the  basis  for 
the  larger  data  interchange  within  the  web,  RuleML  covers  the  entire  rule  spectrum,  from 
derivation  rules  to  transformation  rules  to  reaction  rules.  RuleML  can  be  used  to  specify 
queries  and  inferences  in  Web  ontologies,  mappings  between  Web  ontologies,  and 
dynamic  Web  behaviors  of  workflows,  services,  and  agents  [10]. 

The  RuleML  package  provides  a  namespace  for  XML,  facilitating  reuse.  Top- 
down  or  bottom-up  rules  can  be  used,  specifying  deductive  logic,  rewriting,  and 
inference.  Rules  can  be  stated  in  natural  language,  some  formal  notation  (e.g.,  Backus- 
Naur  form),  or  in  a  combination  of  both.  The  combination  of  natural  language  and  formal 
notation  offers  the  most  nearly  universal  appeal  to  permit  Web-based  rule  storage, 
interchange,  retrieval,  and  application. 

The  RuleML  namespace  has  a  hierarchy  of  rules  that  consists  of  varying 
categories:  reaction,  transformation,  derivation,  facts,  queries,  and  integrity  constraints. 
The  hierarchy  is  shown  in  Figure  8,  where  two  main  categories  of  reaction  rules  and 
transformation  rules  form  the  basis  for  all  other  categories  of  rules. 
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Figures.  RuleML  Hierarchy,  from  [10] 

While  general  rules,  as  the  all-encompassing  rule  category,  could  implement  all 
other  categories  of  rules,  special-purpose  syntaxes  for  each  of  the  subcategories  were 
created  to  allow  for  ease  of  refinement  and  application.  The  following  show  basic  markup 
syntaxes  for  each  of  the  various  categories: 

•  Reaction  rules:  <react>  <_event>  trigger  </_event>  <_body>  <and> 
preml  ...  premN  </and>  </_body>  <_head>  action  </_head>  </react> 
reducible  to  <rule>  <_event>  trigger  </_event>  <_body>  <and>  preml 

...  premN  </and>  </_body>  <_head>  action  </_head>  <_foot>  empty 
</_foot>  </rule> 

•  Transformation  rules:  <trans>  <_head>  cone  </_head>  <_body>  <and> 
preml  ...  premN  </and>  </_body>  <_foot>  value  </_foot>  </trans> 
reducible  to  <rule>  <_event>  active  </_event>  <_body>  <and> preml  ... 

premN  </and>  </_body>  <_head>  cone  </_head>  <_foot>  value 
</_foot>  </rule> 

•  Derivation  rules:  <imp>  <_head>  cone  </_head>  <_body>  <and> preml  ... 
premN  </and>  </_body>  </imp>  reducible  to  <trans>  <_head>  cone 

</_head>  <_body>  <and>  preml  ...  premN  </and>  </_body>  <_foot> 
true  </  foot>  </trans> 
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•  Facts:  <fact>  <_head>  cone  </_head>  </fact>  reducible  to  <imp> 
<_head>  cone  </_head>  <_body>  <and>  </ and>  </_body>  </ imp> 

•  Queries:  <query>  <_body>  <and>  preml  ...  premN  </and>  </_body> 
</query>  redueible  to  <imp>  <_body>  <and>  preml  ...  premN  </and> 
</_body>  <_head>  bindings(  varl,  ...,  varK )  </_head>  </imp> 

•  Integrity  eonstraints:  <ic>  <_body>  <and>  preml  ...  premN  </and> 
</_body>  </ic>  reducible  to  <query  kind="closed">  <_body>  <and> 
preml  ...  premN </and>  </_body>  </query> 

Reaetion  rules  ineorporate  various  produetion,  action,  reaction,  complex  event 
notification,  event  messaging  and  temporal  or  aetion  logie  rules.  These  rules  can  be 
reduced  to  general  rules  that  return  no  value  and  these  rules  ean  only  be  applied  in  the 
forward  direetion  in  a  natural  fashion,  cheeking  (observing)  for  events  (conditions)  and 
performing  an  aetion  if  and  when  all  events  have  been  recognized  (fulfilled).  Reaction 
rules  allow  for  event  notification  and  messaging  between  services,  as  well  as  temporal 
and  state-based  logic  rules.  These  types  of  rules  still  provide  structure  to  aeeommodate  a 
wide  range  of  business  eases  in  their  expressiveness.  Production  rules  are  aetion  rules 
where  a  eondition  is  met,  the  IF,  and  an  action  is  taken,  the  DO.  Action  rules  eonsist  of 
triggers,  the  ON,  resulting  in  the  action,  the  DO.  Overall,  reaction  rules  are  most  often 
exemplified  as  logie  rules  like  those  used  in  a  firewall  configuration.  The  forward 
chaining  of  rules  is  popular  with  expert  systems  and  production  rule  systems.  Forward 
chaining  uses  data  points  against  the  ruleset  to  infer  additional  information,  as  the  data  is 
compared  to  the  existing  rules.  By  ehecking  the  anteeedent  or  IF  clause  of  a  rule,  the 
consequent  or  THEN  can  be  inferred.  These  conelusions  then  add  further  data  points  to 
use  against  the  ruleset  until  an  endstate  or  goal  elause  is  reached.  Overall,  forward 
chaining  ends  with  a  result  based  on  the  original  data  and  additional  data  points  arriving 
from  a  ehanging  situation  can  quickly  be  addressed  by  an  existing  ruleset  to  gain 
additional  inferences  and  realize  a  new  endstate. 

In  contrast,  the  backward  direction  is  normally  preferred  for  transformation  rules. 
The  category  of  rules  ean  be  redueed  to  general  rules  whose  event  trigger  is  always 
activated.  Backward  chaining  begins  with  a  result  and  seeks  to  find  rules  that  will  support 
the  endstate.  Each  of  the  eonsequents,  or  IF  statements,  that  are  required  to  reach  the  goal 
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endstate  are  added  to  the  inference  chain  as  items  to  resolve  and  additional  goals  to 
match.  This  method  is  used  in  automated  theorem  provers  and  expert  systems  and  uses 
the  goals  to  determine  which  rules  become  active,  as  opposed  to  checking  the  rules  with 
the  data  given  and  inferred  as  in  the  forward  chaining  process. 

Derivation  rules  can  be  reduced  to  transformation  rules  that  on  success  return 
true.  They  can  be  applied  in  the  forward  direction  or  in  the  backward  direction  equally. 
The  backward  direction  reduces  the  proof  of  a  goal  (conclusion)  to  proofs  of  all  its  sub¬ 
goals  (premises).  Since  in  different  situations  different  application  directions  of 
derivation  rules  may  be  optimal  (forward,  backward,  or  mixed),  RuleML  does  not 
prescribe  or  restrict  any  one  of  these.  Facts  can  be  reduced  to  derivation  rules  that  have 
an  empty  conjunction  of  premises  {true),  and  facts  or  unit  clauses  have  no  applied 
direction.  Derivation  rules  are  based  on  reasoning  and  typically  expressed  as  an  IF-THEN 
relationship. 

RuleML  also  supports  the  use  of  queries  within  the  basic  code  structure.  These 
queries  can  be  reduced  (transformed)  into  derivation  rules.  Each  query  transformed  to  a 
derivation  rule  will  have  a  false  conclusion.  Queries  also  are  applied  as  top-down  goals 
and  can  be  proven  backwards;  but  they  can  also  be  proved  forward  via  goal-directed 
bottom-up  processing.  Integrity  constraints  can  be  reduced  to  queries  that  produce  no 
variable  bindings  (closed),  and  are  usually  forward-oriented  (i.e.,  triggered  by  update 
events).  However,  integrity  constraints  can  also  be  backward-oriented,  to  show 
(in)consistency  by  fulfdling  certain  conditions  (without  recognizing  an  event). 

In  this  research,  reaction  rules  will  be  used  to  provide  a  forward  chaining  path  to 
demonstrate  the  viability  of  specifying  a  security  policy  for  the  information  broker.  The 
overall  ruleset  is  simplified  to  account  for  a  limited  number  of  cases  as  presented  in  this 
work.  The  use  of  more  sophisticated  rulesets  and  using  other  types  of  RuleML  rules,  like 
derivation  and  transformational  rules,  is  not  explored  but  is  possible  with  this 
specification. 
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III.  OPERATIONAL  CONTEXT 


The  operational  context  of  our  study  is  the  Navy  Tactical  Exploitation  of  National 
Capabilities  (TENCAP)  Program’s  prototype  information  brokering  system  named 
Radiant  Alloy.  Radiant  Alloy  is  a  service-oriented,  multilevel  secure,  enterprise 
information  system  designed  to  provide  confidentiality  for  users  of  varying  security 
levels,  and  data  stores  of  various  security  levels  over  heterogeneous  domains.  Radiant 
Alloy  provides  a  trusted  means  for  sharing  both  unclassified  and  sensitive  data  among 
diverse  user  levels  and  domains,  while  maintaining  anonymity  of  the  data  source,  as 
depicted  in  Figure  9. 
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Two  separate  security  levels  (A  and  B)  are  shown,  along  with  the  system’s 
intention  to  prevent  interaction  between  the  levels  during  its  use,  indicated  by  the  “No 
Transfer”  bar.  The  information  broker  (IB)  resides  behind  firewalls  and  network  edge 
protection,  yet  is  accessible  using  web  services  (WS)  for  a  mixed  MLS-RBAC  model 
where  MLS  will  divide  varying  levels  of  systems  such  as  JWICS  (Top  Secret),  SIPRnet 
(Secret)  and  NIPRnet  (Unclassified).  RBAC  will  be  used  within  each  domain  to  enforce 
further  control  of  access  (i.e.,  finer  granularity)  based  on  the  roles  of  individual  users. 
The  IB  is  also  expected  to  prevent  inadvertent  disclosure  of  information  between  security 
domains  and  facilitate  authorized  sharing  (i.e.,  answer  valid  queries)  among  classification 
domains.  This  is  a  critical  capability  of  interest  to  both  the  Homeland  Defense  and 
Security  communities.  The  IB  must  also  allow  authorized  transfer  and  downgrading  of 
data  for  users  of  differing  domains.  The  Trusted  Data  Connector,  shown  in  Figure  9,  is 
the  plug-in  point  for  the  data  repositories  and  serves  as  the  trusted  service  within  the 
system.  Our  Use  Cases  and  Misuse  Cases  capture  example  scenarios  in  which  the 
information  is  needed  to  be  shared  between  different  domains  and  the  inferences  that 
need  to  be  prevented  while  sharing  this  information. 

Data  accesses  are  controlled  by  the  IB  core  and  the  trusted  data  connector  for  each 
security  level,  where  the  IB  is  replicated.  In  a  MLS  system,  the  IB  must  be  replicated  to 
allow  for  separation  of  the  domains.  However,  this  adds  complexity  to  the  system  since 
the  IB  must  now  maintain  consistency  between  implementations,  in  addition  to  isolating 
users  from  the  data  sources.  The  IB  must  also  support  global  and  local  instantiations  for 
each  of  its  domains.  The  localized  version  will  allow  for  finer  and  more  restrictive 
control  at  a  local  level,  but  must  be  integrated  and  verified  against  the  global  IB  for 
access  requests.  While  the  local  IB  policy  must  be  equal  to  or  more  restrictive  than  the 
global  IB  for  accesses,  it  must  also  verify  requests  with  the  global  version  to  enforce  the 
more  restrictive  control;  that  is,  the  local  version  cannot  give  more  access,  it  can  only 
lessen  the  level  of  access.  This  would  also  account  for  changes  made  at  the  global  IB  that 
may  not  yet  be  reflected  in  a  localized  instantiation  of  the  IB  for  that  security  domain. 
Each  IB  will  have  a  separate  Policy  Decision  Point  (PDP)  to  evaluate  access  requests. 
This  local  decision  must  be  sent  to  the  master  or  global  PDP  to  combine  the  access 
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decision  into  a  finalized  context.  The  IB  must  also  allow  for  a  user  to  have  write  access  to 
a  lower  level  data  store  (which  is  explicitly  forbidden  in  the  BLP  model),  as  well  as 
preventing  leakage  from  different  domains.  The  information  broker  must  enforce  a  mixed 
model  access  controller  to  provide  the  separation  of  users  and  data  necessary  to  protect 
and  enforce  the  confidentiality,  integrity,  and  availability  in  a  MLS  system,  as  opposed  to 
a  monolithic  security  kernel  that  brokers  all  accesses  and  controls  all  resources.  The  IB 
also  serves  as  a  request  broker  for  use  with  many  different  back-end  data  sources.  The  IB 
must  ensure  that  all  requests  are  executed  within  the  databases  at  the  security  level  at 
which  requests  are  made  and  limits  the  results  based  on  the  clearance  of  the  requesting 
user  or  the  classification  level  of  the  network  connection  whichever  is  more  restrictive. 
The  user  is  authenticated  to  the  IB  and  not  to  the  data  source  directly,  thus  never 
obtaining  permissions  for  the  true  data-store  object.  This  provides  anonymity  and 
integrity  of  the  source,  as  well  as  prevents  users  from  undesired  (from  a  security 
viewpoint)  file  operations  [63]. 

Trusted  sharing  among  classification  domains  is  a  critical  capability  of  interest  to 
both  the  Homeland  Defense  and  Homeland  Security  communities.  The  IB  must  also 
allow  authorized  transference  and  downgrading  of  data  for  users  of  differing  domains. 
Radiant  Alloy  will  provide  a  means  of  secure^^  and  trusted^^  information  sharing  that  is 
currently  non-existent  at  the  enterprise  level  across  communities  of  interest.  The  ideas  of 
a  secure  system  and  a  trusted  system  lead  us  to  the  certification  and  accreditation  process, 
where  the  trusted  system  is  one  that  meets  “well  defined  requirements  under  an 
evaluation  by  a  credible  body  of  experts  who  are  certified  to  assign  trust  ratings  to 
evaluated  products  and  systems”  [3].  This  process  allows  us  to  assign  a  level  of  trust  to 
the  architecture,  implementation,  life  cycle  and  management,  and  disposal  of  the  system 
to  meet  the  information  assurance  requirements  necessary  for  the  intended  application. 
As  the  level  of  trust  increases,  so  do  the  number  of  requirements  and  the  stringency  of 

14  Secure  sharing  refers  to  the  ability  of  the  system  to  protect  the  confidentiality  of  information  from 
inappropriate  access  across  the  varying  security  domains  [3]. 

15  Trusted  sharing  refers  to  the  level  of  confidence  or  belief  that  users  have  in  the  ability  of  the  system 
to  protect  their  information  and  resources  across  those  same  domains  to  be  safe  from  compromise  [3], 
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those  requirements.  Ultimately,  we  cannot  guarantee  a  system  to  be  secure  but  we  can 
assert  a  level  of  trust  to  the  protections  and  security  mechanisms'^  the  system  affords. 
This  includes  the  implemented  functionality,  as  well  as  the  assurance  that  the 
functionality  is  correct.  No  SOA  system  has  been  accredited  at  a  High  Assurance  level. 
One  of  the  reasons  for  the  overall  lack  of  certified  and  accredited  systems  is  that  the 
architectural  implementation  and  the  security  policies  that  we  are  trying  to  enforce  within 
that  system  are  difficult  to  implement,  while  maintaining  the  viability  of  the  original 
system  intent.  Security  properties,  and  the  formal  models  associated  with  them,  can  be 
used  to  gain  improvements  in  effectiveness,  efficiency  and  correctness  of  a  system’s 
security  properties.  But,  bridging  the  gap  between  security  requirements  and  the  security 
mechanisms  used  in  an  implementation  is  very  complex  and  expensive.  When  designing 
a  system  architecture  to  support  a  foundational  requirement  of  security,  we  often  lose 
capabilities  in  other  areas,  such  as  usability  or  performance.  This  has  become  a  stumbling 
block  in  creating  and  fielding  systems,  because  if  they  meet  the  requirements  for  High 
Assurance  they  often  sacrifice  in  other  areas  and  might  not  meet  the  user  needs.  Navy 
(TENCAP)  is  attempting  to  build  a  service-oriented  architecture  that  supports  MLS. 
Figure  10  depicts  the  proposed  system  architecture  for  Radiant  Alloy  at  the  high- 
assurance  level.  This  architecture  supports  multiple  user  bases,  multiple  data  stores,  and 
industry- standard  protocols  for  implementation,  through  the  use  of  a  mixed  model  access 
control  (MMAC)  policy.  In  the  MDA  context,  Radiant  Alloy  offers  the  ability  of  an 
Unclassified  user  to  obtain  data  from  a  data  store,  while  a  Secret  user  is  obtaining  a 
similar  data  feed  (but  with  more  detail  commensurate  with  the  classification)  from  the 
same  data  source.  It  becomes  a  significant  problem,  however,  if  a  lower  level  user  can 
observe  any  service  delays  when  the  higher  level  user  is  being  served  by  the  system.  This 
then  becomes  a  covert  channel,  which  is  contrary  to  one  of  the  primary  objectives  of  an 
MLS  system,  that  being  preventing  creation  of  covert  channels.  This  becomes  not  only  a 
challenge  to  designing  and  implementing  a  system,  but  also  to  the  certification  process  to 
ensure  that  it  is  free  of  covert  channels  or  that  the  channels  have  very  limited  bandwidth 


16  Security  Mechanism  is  a  method,  tool,  or  procedure  for  enforcing  a  security  policy  [3]. 
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where  the  risk  of  exploit  can  be  accepted  by  the  system  owner.  In  a  shared  resource 
system,  it  becomes  impossible  to  remove  all  the  covert  channels.  This  ability  to  share 
data,  without  attribution  to  the  source,  and  to  multiple  users  among  differing  domains 
concurrently,  would  serve  as  a  true  combat  multiplier  for  our  military. 


Figure  10.  Radiant  Alloy  Architecture  for  High- Assurance,  from  [7] 


Collection  and  dissemination  of  information  are  handled  well  by  single-level 
systems,  within  homogenous  domains.  When  we  move  out  of  that  context,  our 
information  sharing  abilities  become  more  challenging  and  the  sharing  of  information  can 
rapidly  degrade  if  our  systems  are  not  designed  to  accommodate  this  sharing.  This  is 
attributable  to  both  our  military’s  mindset  toward  not  giving  away  anything  the  enemy 
might  use  against  us,  as  well  as  the  technological  difficulty  of  creating  an  information 
system  that  we  can  trust,i^  to  reliably  and  securely  share  data  without  compromise. 
Architectures,  particularly  distributed  and  service-oriented  architectures,  pose  a  challenge 

17  Trust  is  a  measure  of  trustworthiness,  relying  on  the  evidence  provided;  where  an  entity  is 
trustworthy  if  there  is  sufficient  credible  evidence  leading  one  to  believe  that  the  system  will  meet  a  set  of 
given  requirements  [3]. 
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to  meeting  security  requirements  for  a  multilevel  system.  However,  security  SOA 
systems  are  experiencing  greater  integration  with  current  MLS  systems.  This  integration 
results  in  a  greater  need  for  solid,  technical-based  security  assurances  for  the  architecture. 
This  is  based  on  the  additional  security  requirements  that  a  MLS  system  is  designed  to 
meet,  which  provide  some  level  of  trust  and  assurance  to  the  user.  It  is  with  this  intent 
that  we  developed  our  Maritime  Domain  Awareness  scenario. 
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IV.  USAGE  SCENARIOS 


A.  MARITIME  DOMAIN  AWARENESS  HIGH  LEVEL  ALERT  SCENARIO 

Our  application  scenario  conies  from  Maritime  Domain  Awareness  (MDA)'^, 
which  would  encompass  the  proposed  Radiant  Alloy  system.  The  SysML^^  view  of  this 
domain  example  is  shown  in  Figure  11. 


bdd  [Package]  Structure  |[MDA Domain]^ 


Figure  1 1 .  MDA  Domain  SysML  Diagram 


In  the  scenario,  ships  depart  Southeast  Asia  and  sail  toward  ports  on  the  West 
Coast  of  the  United  States.  Under  normal  circumstances  the  harbormasters  at  these  ports 
share  information  about  the  ships  expected  departure  and  arrival  times  and  contents  of  the 
cargo.  In  addition,  other  external  resources  develop  information  (which  originates  in 

1 8  Maritime  Domain  Awareness  is  the  effective  understanding  of  anything  associated  with  the 
maritime  domain  that  could  impact  the  security,  safety,  economy,  or  environment  of  the  United  States. 

19  The  Systems  Modeling  Language  (SysML)  is  general  purpose  visual  modeling  language  for 
systems  engineering  applications.  SysML  supports  the  specification,  analysis,  design,  verification  and 
validation  of  a  broad  range  of  systems  and  systems-of-systems. 
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different  systems  with  higher  classification  levels  that  emits  system-high  alerts)  that  may 
mandate  extensive  searches  of  ships  that  take  this  normal  course,  the  information  ought  to 
be  shared  in  a  way  that  hides  the  sources  (and  methods  of  collection)  of  the  information, 
and  make  it  appear  to  be  information  received  through  pre-arranged  communication 
channels.  For  this  research,  assume  that  USS  Antietam  (CG-54),  which  is  performing  an 
interdiction  mission  in  international  waters  in  the  Pacific  Ocean,  can  generate  high-level 
alerts  about  other  ships.  The  Use  Case  (shown  in  Figure  12)  can  be  extended  to  the 
application  scenario  as  follows: 

•  The  ship  Globalstar?  becomes  identified  as  a  Vessel  of  Interest  (VOI). 

•  The  USS  Antietam  encounters  Globalstar?  in  international  waters  and 

stops  the  ship  as  part  of  its  mission  or  merely  observes  the  ship  via  other 
means. 

•  The  Electronic  Warfare  Officer  (EWO)  onboard  the  USS  Antietam, 

utilizing  available  sources  of  information,  obtains  data  about  the  VOI  and 
aggregates  data  from  these  sources. 

•  The  EWO  updates  the  track  for  the  Globalstar?  in  accordance  with  his 
duties  and  responsibilities. 

•  The  EWO  sends  an  Alert  Notification  to  the  destination  port’s 

Harbormaster. 

•  The  notification  advises  the  destination  port  (San  Diego)  to  watch  for  the 
VOI  (i.e.,  Globalstar?)  and  alert  upon  arrival. 


Figure  12.  High  Level  Alert  Use  Case  Diagram 
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Within  the  system  boundaries  an  Information  Broker  is  the  key  respondent  to 
access  requests,  information  queries,  and  data  access.  The  system  architecture  for  the 
MDA  scenario  and  the  Use  Case  is  shown  in  Figure  13  and  Figure  14. 


Figure  13.  Graphical  Representation  of  Use  Case  System  Architecture 
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While  considering  the  system  architecture  and  the  overall  scenario  for  the  Use 
Case,  we  must  illustrate  the  actions  for  all  actors  with  a  UML  Sequence  Diagram,  as 
shown  in  Figure  15. 


Figure  15.  Sequence  Diagram  for  High  Level  Alert  MDA  Scenario 


The  sequence  diagram  also  depicts  the  mal-actor  as  an  alternative  flow  of  events, 
since  he  is  not  overtly  trying  to  misuse  the  system.  His  actions  are  merely  in  the 
performance  of  his  duties  and  show  the  sequencing  that  results  from  the  system 
interaction. 
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1. 


High  Level  Alert  Use  Case 


During  the  performance  of  duty  on  the  USS  Antietam,  the  EWO  has  (Top  Secret 
level)  data  via  a  variety  of  intelligence  means  (e.g.,  electronic,  signals,  and  human 
[ELfNT,  SIGINT,  HUMINT])  to  confirm  ship,  track  and  other  details  which  from  the 
composition  of  the  data  sources  can  give  an  aggregate  picture  of  the  VOL  These  sources 
can  also  be  used  to  compose  other  attributes,  such  as  track  history,  port  history,  or  even 
Measurement  and  Signature  Intelligence  (MASINT)  data  signatures  that  may  be  lacking 
from  the  original  information  about  the  ship.  This  combined  data  represented  in  a  new 
and  more  detailed  view,  then  categorizes  at  a  higher  classification  level  than  originally 
intended  (i.e..  Top  Secret  instead  of  Unclassified).  Table  5  shows  the  detailed  Use  Case 
for  the  Electronic  Warfare  Officer  serving  onboard  the  USS  Antietam. 


Tables.  High  Level  Alert  EWO  Use  Case 


Item 

Contents 

Use  Case  Name 

Ul-High  Level  Alert 

Actors 

EWO  (Top  Secret) 

Brief  description 

EWO  is  aboard  a  U.S.  Navy  Cruiser  class  ship 
performing  an  interdiction  mission.  EWO  is  responsible 
for  information  and  tracking  of  all  ships  in  a  theater  of 
operation  using  ELINT,  SIGINT,  HUMINT,  IR,  and 
imagery.  For  vessels  of  interest,  the  EWO  can  query  and 
update  information  in  the  system  regarding  those  ships 
via  his  array  of  data  collection  sources. 

For  particular  vessels  of  interest,  the  EWO  can  put  a 
watch  on  those  ships  at  arriving  ports  and  monitor  via 
intelligence  methods  available  to  him. 

Flow  of  events 

1 .  EWO  (Top  Secret)  logs  in  to  the  system  (IB) 

2.  IB  authenticates  user  to  PDF 

3.  IB  creates  a  session  for  the  user 

4.  EWO  requests  data  via  a  query  to  the  IB 

5.  IB  queries  data  stores 

6.  IB  provides  data  (TOP  SECRET  and  below)  to 
the  EWO 

7.  EWO  synthesizes  data  and  updates  track  and 
vessel  information. 
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Item 

Contents 

8.  EWO  requests  IB  to  write  data  into  the  system. 

9.  IB  verifies  EWO  to  PDF 

10.  IB  performs  write  operation  to  data  store 

Alternative  flow  of  events 

1 .  EWO  (TOP  SECRET)  logs  in  to  the  system  (IB) 

2.  IB  authenticates  user  to  PDF 

3.  IB  creates  a  session  for  the  user 

4.  EWO  requests  data  via  a  query  to  the  IB 

5.  IB  queries  data  stores 

6.  IB  provides  data  (TOP  SECRET  and  below)  to 
the  EWO 

7.  EWO  exits  the  system 

Precondition 

User  is  an  authorized  user  of  the  system  and  has  a  valid 
role  (EWO)  established  in  the  system. 

TOP  SECRET  level  access  to  the  system  is  available  via 
a  terminal. 

Post-condition 

User  is  authorized  user  of  the  system  and  has  a  valid  role 
(EWO)  established  in  the  system. 

The  Unclassified  level  hosts  another  actor  for  the  Use  Case.  This  actor  is  the 
Harbormaster  (role)  for  the  port  of  San  Diego  where  the  Alert  Notification  will  be 
directed.  The  Harbormaster  is  responsible  for  all  inbound  and  outbound  traffic  for  the 
entire  port.  He  must  manage  berthing  space  and  overall  flow  in  the  performance  of  his 
role.  The  Harbormaster  is  also  obligated  to  comply  with  alert  messages  and  adhere  to  his 
primary  responsibilities.  Based  on  an  Alert  Notification,  the  Harbormaster  is  instructed  to 
watch  for  Globalstar?  arriving  at  an  approximate  date- time  group  (DTG)  from  the  Port 
of  Shanghai,  China  and  report  upon  arrival.  Table  6  depicts  the  detailed  Use  Case  actions 
for  the  Harbormaster. 


This  is  a  messaging  time  format  used  by  the  U.S.  military. 
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Table  6.  High  Level  Alert  Harbormaster  Use  Case 


Item 

Contents 

Use  Case  Name 

Ul-High  Level  Alert 

Actors 

Harbormaster  (Unclassified) 

Brief  description 

Harbormaster  is  responsible  for  inspection  and 
management  of  all  ships  entering  and  leaving  the  port.  He 
must  know:  Existence  of  the  vessel,  scheduled  arrival, 
reported  size,  port  of  origination,  other? 

Using  the  harbormaster  role;  allows  for  queries  to  the 
system  for  information  pertaining  to  origination  port, 
destination  port,  expected  arrival  time  (window),  size/class 
of  vessel,  and  name. 

Flow  of  events 

1 .  User  (UC)  logs  in  to  the  system  (IB) 

2.  IB  authenticates  user  to  PDP 

3.  IB  creates  a  session  for  the  user 

4.  User  requests  data  via  a  query  to  the  IB 

5.  IB  finds  the  relevant  data  store 

a.  Managed  by  this  IB 

b.  Managed  by  another  IB 

6.  IB  queries  the  data  store(s) 

7.  IB  provides  data  that  meets  the  query  criteria  and 
that  is  authorized  per  the  Role-Permission  mapping 
and  security  level  for  the  Harbormaster 

Alternative  flow  of  events 

1 .  User  (UC)  logs  in  to  the  system  (IB) 

2.  IB  authenticates  user  to  PDP 

3.  IB  creates  a  session  for  the  user 

4.  User  requests  data  via  a  query  to  the  IB 

5.  IB  finds  the  relevant  data  store 

6.  Managed  by  this  IB 

7.  Managed  by  another  IB 

8.  IB  queries  the  data  store(s) 

9.  Harbormaster  is  not  authorized  any  data  and  IB 
provides  a  negative  data  found  response 

Precondition 

User  is  an  authorized  user  of  the  system  and  has  a  valid  role 
(Harbormaster)  established  in  the  system. 

Access  is  available  via  a  terminal  to  the  information  system 

Post-condition 

User  is  authorized  user  of  the  system  and  has  a  valid  role 
(Harbormaster)  established  in  the  system. 

Data  is  used  to  perform  the  duties  of  Harbormaster 
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These  two  aetors  in  these  two  Use  Cases  (i.e.,  EWO  and  Harbormaster)  that  are 
operating  at  different  seeurity  levels  eombine  their  roles  to  perform  a  standard  maritime 
mission.  These  aetions,  however,  and  the  aetors’  associated  duties  and  responsibilities, 
also  establish  a  basis  for  our  Misuse  Case. 

2.  High  Level  Alert  Misuse  Case 

The  Misuse  case  is  designed  to  reveal  a  security  problem,  where  the  system  is  not 
performing  its  intended  use.  The  mal-actor  in  this  Misuse  Case  is  actually  one  of  our 
actors  from  the  use  case,  the  Harbormaster.  After  receiving  an  Alert  Notification 
concerning  the  vessel  of  interest,  the  Port  of  San  Diego  Harbormaster  queries  his  system 
for  all  ships  destined  to  his  port  and  originating  from  the  Port  of  Shanghai.  But,  the 
Globalstar?  does  not  show  on  this  list-from  this  the  Harbormaster  can  infer  that  someone 
knew  about  this  ship  and  its  questionable  nature  (since  he  was  told  to  watch  for  its 
arrival)  but  he  was  not  authorized  this  information  from  his  access  to  the  system.  Now, 
there  is  an  unintended  flow  (existence)  of  Top  Secret  information  to  the  lower 
(Unclassified)  level,  and  the  creation  of  a  covert  channel,  violating  the  *-property  (i.e.,  no 
write  down)  of  the  BLP  model.  The  Misuse  Case  system  architecture  overview  is  shown 
in  Figure  16  and  Figure  17,  while  the  detailed  Misuse  Case  is  shown  in  Table  7. 


Figure  16.  Graphical  Representation  of  Misuse  Case  System  Architecture 
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Figure  17.  Misuse  Case  System  Architecture 
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Table  7.  High  Level  Alert  Misuse  Case 


Item 

Contents 

Misuse  Case  Name 

MU  1 -High  Level  Alert  (Transition  to  Lower  Level) 

Actors 

Harbormaster  (Unelassified),  Electronie  Warfare  Offieer  (TOP 
SECRET) 

Brief  Description 

The  Harbormaster  is  informed  of  a  Watch  Alert  for  a  particular  ship 
(GlobalstarV),  inbound  from  Shanghai,  China  to  arrive  at  an 
approximate  DTG. 

Harbormaster  logs  in  to  the  system  and  requests  data  from  the 
system  (using  one  of  his  authorized  queries)  for  all  ships  arriving  to 
his  port  (San  Diego)  from  the  Port  of  Shanghai,  China. 

The  system  (IB)  provides  data  to  the  Harbormaster  based  upon  his 
role  and  clearance  level,  but  that  ship  (Globalstar?)  is  not  in  the 
data  set  provided  by  the  system. 

Around  the  approximated  DTG  the  Globalstar?  ship  arrives  in  his 
port. 

The  Harbormaster  can  infer  that  he  was  not  privileged  to  this 
information  and  that  the  system  has  other  types  of  collection  / 
reporting  assets  that  created  and  verified  this  ship’s  track. 

Flow  of  Events 

1 .  User  (UC)  logs  in  to  the  system  (IB) 

2.  IB  authenticates  user  to  PDP 

3.  IB  creates  a  session  for  the  user 

4.  User  requests  data  via  a  query  to  the  IB 

5.  IB  finds  the  relevant  data  store 

a.  Managed  by  this  IB 

b.  Managed  by  another  IB 

6.  IB  queries  the  data  store(s) 

7.  IB  provides  data  that  meets  the  query  criteria  and  that  is 
authorized  per  the  Role-Permission  mapping  and  security 
level  for  the  Harbormaster 

Alternative  Flow  of 
Events 

1 .  User  (UC)  logs  in  to  the  system  (IB) 

2.  IB  authenticates  user  to  PDP 

3.  IB  creates  a  session  for  the  user 

4.  User  requests  data  via  a  query  to  the  IB 

5.  IB  finds  the  relevant  data  store 

a.  Managed  by  this  IB 

b.  Managed  by  another  IB 

6.  IB  queries  the  data  store(s) 

7.  Harbormaster  is  not  authorized  any  data  and  IB  provides  a 
negative  data  found  response 
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Item 

Contents 

Precondition 

User  is  eleared  (Unclassified)  and  has  a  role  (Harbormaster)  in  the 
system 

Assumption 

A  ship  exists  that  is  of  a  particular  concern  and  has  a  track  related 
update  performed  by  a  higher  elearance  level  user. 

Exploited 

Vulnerability 

An  out  of  band  signaling  ehannel  exists  and  is  utilized  in  the 
performanee  of  duties. 

Worst  Case  Threat 

The  Harbormaster  can  make  an  inference  from  the  out  of  band 
signaling  about  the  system  and  divulge  privileged  information. 
Could  also  divulge  the  identity  of  the  sender  (for  the  Alert) 

Capture  Guarantee 

No  out  of  band  (outside  of  system)  eommunication  is  allowed  (via 
phone,  email,  ete.).  All  eommunications  must  go  through  the 
system  (and  the  IB). 

Related  Business 
Rules 

Seope  of  duty  for  the  EWO  to  report  the  threat  as  an  Alert 
notification  to  the  harbor  and  within  the  seope  of  duty  for  the 
Harbormaster  to  aeknowledge  and  respond/watch  for  the  vessel 
indieated  in  the  alert  notification. 

Potential  Misuse 
Profile 

This  misuse  could  happen  aceidentally  and  does  not  require  ability 
or  skill  beyond  that  of  a  normal  Harbormaster  user  who  can  query 
the  system  and  possesses  an  average  intelleet  to  infer  that  someone 
knew  about  the  ship’s  arrival,  but  it  was  not  in  the  system. 
Intentionally,  the  misuse  can  be  exploited  using  other  authorized 
queries  (per  the  Harbormaster  role)  against  other  faets  (i.e.,  DTG  of 
expected  arrival,  size  of  ship,  destination  port,  or  ship  name). 

Stakeholders  and 
Threat 

System  Designers  /  Developers-system  implementation  is 
eompromised  because  of  the  out  of  band  signaling  used 

Certifiers  &  Aeereditors-system  does  not  provide  assuranee  and 
meet  requirements  to  pass  eertification 

Trainers  for  the  users  (Actors)  in  the  system-users  do  not  perform 
their  duties  as  instrueted  and  open  the  out  of  band  signaling  ehannel 
to  compromise  the  system 

Scope 

Maritime  seenario 

This  scenario  is  certainly  not  limited  to  this  single  misuse.  It  is  merely  being 
offered  as  an  example  scenario  to  drive  the  Use  Case  analysis  and  to  provide  a  basis  for 
the  system’s  response  via  the  Seeurity  Use  Case. 
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3.  High  Level  Alert  Security  Use  Case 

Our  problem  that  originates  from  this  Misuse  Case  is  the  uncontrolled 
observability  of  differing  security  domains.  This  violates  the  safety  of  both  access  control 
models  within  the  system  and  the  specified  information-flow  control  policies.  The 
combination  of  use  and  misuse  necessitates  a  Security  Use  Case  to  mitigate,  detect,  or 
prevent  an  associated  misuse  [64,  65].  This  Security  Use  Case  represents  the  system’s 
method  of  dealing  with  the  vulnerabilities  the  Misuse  Case  exploited  within  the  system. 
By  analyzing  the  interactions  of  Use  and  Misuse,  and  then  the  associated  Security  Use 
Case-we  can  develop  better  system  requirements  that  will  prevent  security  breaches  and 
provide  some  type  of  safety  guarantee  for  our  information.  In  this  instance,  the  Misuse 
Case  we  presented  exposes  that  we  have  an  information  flow  and  more  importantly  an 
information  leakage  problem  within  our  system.  The  detection  and  mitigation  of  this 
leakage  requires  a  change  to  the  system  architecture  to  account  for  the  Security  Use 
Case’s  handling  of  the  Use  and  Misuse  Cases.  The  primary  means  to  eliminate  this 
misuse  is  via  the  rerouting  of  information  in  the  system,  as  well  as  adding  a  new 
architectural  element;  the  Information  Declassifier.  The  detection  of  queries  and  alerts 
within  the  system  must  be  supported  by  changing  the  architecture.  The  revised  system 
architecture  for  the  Security  Use  Case  is  shown  in  Figure  18  and  Figure  19.  For  all 
system  data  queries,  the  Information  Broker  must  provide  filtered  information  contained 
in  higher  level  IB  alerts  (or  parts  of  information  from  those  alerts  that  need  to  be  shared 
with  the  levels  below)  that  need  to  be  read  by  the  lower  levels,  and  inject  them  into  the 
lower  level  data  query  so  that  the  covert  channels  created  by  the  missing-information  will 
not  be  there.  The  process  can  be  done  in  two  stages: 

1.  The  views  and  queries  available  to  the  lower  levels  (i.e..  Secret  level)  will 
be  made  available  to  the  Top  Secret  level  at  design  time. 

2.  Create  information  downgrading  rules  between  each  (High,  Low)  level 
pair. 
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This  allows  the  information  that  the  lower  elassification  level  user  is  authorized  to 
view  to  still  be  viewable  (through  the  Alert  and  use  of  the  Information  Declassifier), 
instead  of  suspiciously  absent  because  a  higher  classification  level  user  “touched”  the 
data  and  now  they  cannot  Read  it  (even  though  it  is  within  the  scope  and  permissions  of 
their  Role’s  duties).  This  provides  a  user  with  inference  ability  through  the  lack  of 
information  resultant  from  an  authorized  query  to  the  system. 


Figure  18.  Graphical  Representation  of  Security  Use  Case  System  Architecture 
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Figure  19.  Security  Use  Case  for  IB  System  Architecture 

The  removal  of  higher  clearance  level  attributes  is  essential  to  maintaining  the 
safety  of  the  system  and  hinges  on  the  lower  level  IB  checking  with  a  higher  level  IB. 
Each  IB  must  successively  iterate  the  query  upward  until  the  highest  level  IB  is  reached. 
This  is,  most  likely,  the  global  instance  of  the  Top  Secret  IB.  It  is  this  IB  that  will  give 
the  authoritative  answer  when  lesser  IBs  ask  how  to  respond  to  queries.  This  IB  will  have 
to  inject  the  presence  of  the  GlobalstarV  from  the  Port  of  Shanghai,  in  order  to  prevent 
this  inference  disclosure.  This  information  injection  will  originate  from  the  original  Alert 
that  is  processed  by  the  system  during  the  execution  of  the  EWO’s  duties  and  obligations 
to  report  on  specified  criteria.  But,  it  cannot  just  use  the  entire  alert  message  and  must 
filter  the  contents  of  the  message  based  on  role  permissions  for  the  user  who  executed  the 
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initial  query  that  have  been  mapped  to  the  user’s  role  and  validated  with  the  PDP.  The 
detailed  Security  Use  Case  is  presented  in  Table  8,  Table  9,  Table  10,  and  Table  11. 


Table  8.  High  Level  Alert  Security  Use  Case  (Alert  Detection) 


Item 

Contents 

Use  Case  Name 

SUl-High  Level  Alert  Security  Use  Case 

Actors 

EWO,  Harbormaster 

Brief  description 

Three  sub-cases  exist  for  this  Security  Use  Case  where  the 
system  must  <detect>  interactions  at  different  touch  points. 
These  sub-cases  include: 

1 .  The  system  detects  an  Alert  message  is  being  posted 
from  a  user  (at  any  level). 

2.  The  system  detects  a  user  query  submitted  to  the 
Information  Broker  (at  any  level).  Two  sub-cases 
exist:  positive  presence  of  data,  and  negative 
presence  of  data. 

3.  The  system  detects  an  Inter-IB  query  (a  lower  level 
IB  queries  to  a  higher  level  IB).  Two  cases  exist: 
positive  presence  of  alert  messages  pertaining  to  the 
query,  and  negative  presence  of  alert  messaging 
pertaining  to  the  query. 

Flow  of  events 

1 .  The  system  <detects>  an  Alert  message  and  begins 
processing  lAW  SUl.l 

Alternative  flow  of  events 

1 .  The  system  <detects>  a  query  and  begins  processing 
lAW  SU1.2  (User-IB)  or  SU1.3  (Inter-IB) 

Precondition 

Users  of  the  use  and  misuse  cases  are  authorized  users  of  the 
system  and  have  valid  roles  (EWO  and  Harbormaster) 
established  in  the  system  with  a  common  subset  of 
permissions  mapped  from  the  roles. 

Access  to  the  system  is  available  to  all  users. 

Post-condition 

User  is  authorized  user  of  the  system  and  has  a  valid  role 
established  in  the  system. 
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Table  9.  High  Level  Alert  Security  Use  Case  (Alert  Detection) 


Item 

Contents 

Use  Case  Name 

SUL  1-High  Level  Alert  Security  Use  Case  (Alert  Detection) 

Actors 

EWO,  Harbormaster 

Brief  description 

The  system  detects  an  Alert  message  is  being  posted  and  (a) 
examines  the  message  for  its  distribution  (b)  maps 
permissions  from  the  distribution  roles  (those  who  it  is 
intended  for)  for  accesses  to  those  fields  that  are  contained  in 
the  message  thru  multiple  queries  to  the  PDP  (one  query  for 
each  role  /  user  on  the  distribution  list)  (c)  removes  parts  of 
the  message  (data  fields)  that  are  not  permitted  for  the  roles 
permission  mapping  (d)  transmits  the  message  to  the  roles 
listed  in  the  distribution. 

Flow  of  events 

1 .  An  Alert  message  is  posted  to  the  system  and  stored 
at  the  current  user’s  classification  level. 

2.  The  distribution  list  (recipients)  of  the  message  is 
examined. 

3.  Each  recipient  is  checked  (by  role)  with  the  PDP  for 
permissions  on  that  message  by  field. 

4.  Individual  fields  and  data  are  filtered  from  the 
message  based  on  the  returned  permission  set  (this 
could  be  an  empty  set). 

5.  Message  is  delivered  to  intended  recipients  with 
unauthorized  content  filtered. 

Alternative  flow  of 
events 

1 .  An  Alert  message  is  posted  to  the  system 

2.  The  distribution  list  (recipients)  of  the  message  is 
examined. 

3.  Each  recipient  is  checked  (by  role)  with  the  PDP  for 
permissions  on  that  message  by  field. 

4.  Individual  fields  and  data  are  filtered  from  the 
message  based  on  the  returned  permission  set 
(this  could  be  an  empty  set). 

5.  Message  contains  no  data  available  for  delivery  to  a 
user  and  is  stored  at  the  current  classification  level. 

Precondition 

Users  of  the  use  and  misuse  cases  are  authorized  users  of  the 
system  and  have  valid  roles  (EWO  and  Harbormaster) 
established  in  the  system  with  a  common  subset  of 
permissions  mapped  from  the  roles. 

Access  to  the  system  is  available  to  all  users. 

Post-condition 

User  is  authorized  user  of  the  system  and  has  a  valid  role 
established  in  the  system. 
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Table  10.  High  Level  Alert  Security  Use  Case  (User-IB  Query  Detection) 


Item 

Contents 

Use  Case  Name 

SU1.2-High  Level  Alert  Security  Use  Case  (User-IB 
Query  Detection) 

Actors 

EWO,  Harbormaster 

Brief  description 

There  are  two  alternative  flows  for  this  Use  Case. 

The  system  detects  a  query  has  been  submitted  by  a  user 
to  the  Information  Broker  and  (a)  checks  for  validity  of 
the  query  based  on  permissions  mapped  to  the  user  role 
with  a  permission  query  to  the  PDF  (b)  checks  with  the 
higher  level  Information  Broker  for  Alert  messages  that 
pertain  to  fields  or  values  in  the  query  that  were 
validated  by  the  PDP  permission  response  (c)  removes 
(filters)  information  from  the  query  that  is  not  permitted 
for  viewing  by  the  role  of  the  requestor  (d)  provides  the 
remaining  information  from  the  alert  to  the  lower  level 

IB  (e)  queries  its  own  current  level  repositories  for 
additional  data  matching  the  query  and  allowable  for  the 
role  based  permissions  (f)  aggregates  the  items  from  (d) 
and  (e)  to  provide  data  to  the  user  that  is  allowable  via 
the  role  permissions  assigned  to  the  user. 

Alternatively,  the  system  detects  a  query  has  been 
submitted  by  a  user  to  the  Information  Broker  and  (a) 
checks  for  validity  of  the  query  based  on  permissions 
mapped  to  the  user  role  with  a  permission  query  to  the 
PDP  (b)  checks  with  the  higher  level  Information  Broker 
for  Alert  messages  that  pertain  to  fields  or  values  in  the 
query  that  were  validated  by  the  PDP  permission 
response  (c)  negative  response  for  alert  message 
presence  to  the  lower  level  IB  (d)  queries  its  own 
current  level  repositories  for  additional  data 
matching  the  query  and  allowable  for  the  role  based 
permissions  (e)  provides  data  matching  the  query  and 
allowable  via  the  role  permissions  assigned  to  the 
user. 

Flow  of  events 

1 .  The  system  detects  a  query  has  been  submitted 
by  a  user  to  the  Information  Broker 

2.  Checks  for  validity  of  the  query  based  on 
permissions  mapped  to  the  user  role  with  a 
permission  query  to  the  PDP 

3.  Generates  an  Inter-IB  query,  which  checks  with 
the  higher  level  Information  Broker  for  Alert 
messages  that  pertain  to  fields  or  values  in  the 
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Item 

Contents 

query  that  were  validated  by  the  PDP  permission 
response 

4.  Removes  (filters)  information  from  the  query  that 
is  not  permitted  for  viewing  by  the  role  of  the 
requestor 

5.  Queries  its  own  current  level  repositories  for 
additional  data  matching  the  query  and  allowable 
for  the  role  based  permissions 

6.  Aggregates  the  Inter-IB  query  response  with  the 
original  query  response  at  the  current  IB  level  to 
provide  data  to  the  user  that  is  allowable  via  the 
role  permissions  assigned  to  the  user. 

Alternative  flow  of  events 

1 .  The  system  detects  a  query  has  been  submitted 
by  a  user  to  the  Information  Broker 

2.  Checks  for  validity  of  the  query  based  on 
permissions  mapped  to  the  user  role  with  a 
permission  query  to  the  PDP 

3.  Generates  an  Inter- IB  query  that  checks  with  the 
higher  level  Information  Broker  for  Alert 
messages  that  pertain  to  fields  or  values  in  the 
query  that  were  validated  by  the  PDP  permission 
response 

4.  Receives  a  negative  response  for  alert  message 
presence  from  the  Inter-IB  query 

5.  Runs  the  original  query  against  its  own  current 
level  repositories  for  data  matching  the  query  and 
allowable  for  the  role  based  permissions 

Provides  data  matching  the  query  and  allowable  via  the 
role  permissions  assigned  to  the  user  or  provides  a 
negative  response  to  the  user  for  the  data  query. 

Precondition 

Users  of  the  use  and  misuse  cases  are  authorized  users  of 
the  system  and  have  valid  roles  (EWO  and 

Harbormaster)  established  in  the  system  with  a  common 
subset  of  permissions  mapped  from  the  roles. 

Access  to  the  system  is  available  to  all  users. 

Post-condition 

User  is  authorized  user  of  the  system  and  has  a  valid  role 
established  in  the  system. 

76 


Table  1 1 .  High  Level  Alert  Security  Use  Case  (Inter-IB  Query  Detection) 


Item 

Contents 

Use  Case  Name 

SU1.3-High  Level  Alert  Security  Use  Case  (Inter-IB 

Query  Detection) 

Actors 

EWO,  Harbormaster 

Brief  description 

The  system  detects  an  query  from  a  lower  level  IB  to  a 
higher  level  for  alert  message  data  (which  includes  role  and 
permission  information)  and  (a)  submits  a  similar  type 
query  to  its  higher  level  IB  (bl)  aggregates  a  positive 
response  with  any  additional  alert  messages  that  exist  at  its 
own  level  or  (b2)  after  a  negative  response  from  a  higher 
level  the  IB  queries  its  own  level  for  alert  message 
information  pertaining  to  the  query  and  allowable  via  the 
role  permissions  (c)  provides  either  a  negative  response  to 
the  lower  level  IB  or  the  resultant  data  from  (bl)  or  (b2)  to 
the  lower  level  IB. 

Flow  of  events 

1 .  The  system  detects  an  Inter-IB  query  from  a  lower 
level  IB  to  a  higher  level  for  alert  message  data 
(which  includes  role  and  permission  information) 

2.  Submits  a  similar  type  query  to  its  higher  level  IB 
(unless  it  is  the  authoritative  IB) 

3.  Aggregates  a  positive  response  to  the  Inter-IB 
query  with  any  additional  alert  messages  that  exist 
at  its  own  level 

4.  Filters  the  information  not  permissible  for  the 
user’s  role  permission  set. 

5.  Provides  the  resultant  data  set  from  the  query  to 
the  lower  level  IB. 
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Item 

Contents 

Alternative  flow  of  events 

1 .  The  system  detects  an  Inter-IB  query  from  a  lower 
level  IB  to  a  higher  level  for  alert  message  data 
(which  includes  role  and  permission  information) 

2.  Submits  a  similar  type  query  to  its  higher  level  IB 
(unless  it  is  the  authoritative  IB) 

3.  Receives  a  negative  response  from  a  higher  level 

and  then  queries  its  current  level  for  alert  message 
information  pertaining  to  the  query  and  allowable 
via  the  role  permissions 

4.  Filters  the  information  not  permissible  for  the 
user’s  role  permission  set. 

5.  Provides  either  a  negative  response  to  the  lower 
level  IB  if  the  permission  to  data  mapping  is  empty. 

6.  Provides  a  filtered  result  of  the  data  set  to  the  lower 
level  IB. 

Precondition 

Users  of  the  use  and  misuse  cases  are  authorized  users  of 
the  system  and  have  valid  roles  (EWO  and  Harbormaster) 
established  in  the  system  with  a  common  subset  of 
permissions  mapped  from  the  roles. 

Access  to  the  system  is  available  to  all  users. 

Post-condition 

User  is  authorized  user  of  the  system  and  has  a  valid  role 
established  in  the  system. 

4.  Impact  of  Misuse  and  Mitigation 

Overall,  the  Misuse  Case  exposes  an  information  flow  and  more  importantly  an 
information  leakage  problem  within  our  system.  The  leakage  is  an  inference  about  cross¬ 
domain  information.  The  detection  and  mitigation  of  this  leakage  requires  a  change  to  the 
system  architecture  to  account  for  the  Security  Use  Case’s  handling  of  the  Use  and 
Misuse  Cases.  The  primary  means  to  eliminate  this  misuse  is  via  the  rerouting  of 
information  in  the  system,  as  well  as  adding  a  new  architectural  element;  the  Information 
Declassifier.  The  ID  must  act  as  an  intermediary  between  varying  security  domains, 
represented  by  an  Information  Broker  (IB),  to  process  queries  from  lower  classification 
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levels  and  to  pull  data  pertaining  to  Alert  Notifications  from  higher  classification  level 
data  stores.  This  is  necessary,  because,  if  a  higher  level  user  touches  the  data  pertaining  to 
a  VOI,  the  lower  level  user  can  no  longer  view  that  data,  that  they  are  entitled  to  (in 
performance  of  their  duties  to  fulfill  a  Role).  In  order  to  prevent  such  security  violations, 
Radiant  Alloy  needs  to  use  an  information  declassifier.  In  this  research,  we  provide  a 
policy-based  framework  to  do  so  using  RuleML. 

This  revised  system  architecture  is  a  proposed  goal  of  this  research  and  is  shown 
in  Figure  20.  It  is  in  this  re-architecting  that  we  have  rerouted  all  system  queries  from 
both  users  and  existing  domain  level  information  brokers,  in  order  to  prevent  the  misuse 
of  our  system.  Although  this  figure  depicts  a  singular  Information  Declassifier  (ID),  we 
must  provide  for  ID  replication  throughout  the  system  and  particularly  between  each 
information  domain. 


ActOfTS/SCI 


ActOfUnclass 


All  repository  responses  rerouted 
All  queries  rerouted 


utes  the 

erefle  between 
iswer  and 
iformation 


Declassified  alerts  do 
not  violate  safety  of 
either  access  controller 


Figure  20.  Graphical  Representation  of  System  Architecture  for  Leakage  Mitigation 
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Because  of  this  inter-domain  requirement,  the  ID  serves  as  a  proxy  for  all 
messaging  within  the  system.  It  is  here  where  the  ID  will  take  cleared  messages  and 
include  them  in  referenced  queries,  to  which  the  lower  level  IB  itself  should  not  see 
outright  (because  of  BLP’s  Simple  Security  Property).  This  use  of  an  Information 
Declassifier  adds  complexity  to  our  system  design  and  requires  additional  interactions 
between  domain  level  information  brokers.  Between  each  domain  we  must  have  an  ID 
residing  to  request  and  deliver  information  from  higher  domains.  This  will  be  iterative 
from  the  lowest  IB  domain  level  (e.g..  Unclassified)  up  to  the  highest  level  IB  domain 
(e.g..  Top  Secret),  where  an  ID  will  be  able  to  query  for  Alert  notifications  (or  other  data) 
and  be  able  to  provide  that  as  required  to  a  lower  level  IB  domain.  A  state  chart 
representation  of  the  query  and  alert  process  with  the  interactions  between  separate  IBs 
and  an  ID  is  shown  in  Figure  21.  The  start  state  is  denoted  by  the  solid  black  circle,  the 
arrows  indicate  transition  flow,  and  the  double  circles,  which  encompass  the  IBs  and  ID 
denote  accepting  states  within  the  statechart. 


Figure  2 1 .  Statechart  for  Information  Broker  and  Information  Declassifier  Process 
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As  each  query  is  received  at  an  individual  domain’s  IB,  the  individual  IB  will  first 
perform  its  duties  to  authenticate  the  user,  and  the  user’s  permissions  for  the  requested 
data,  based  on  both  the  user’s  role  permission  set  and  the  classification  level  of  the 
information.  After  a  query  is  acknowledged  as  valid  within  the  IB,  the  IB  will  forward 
the  user  query  to  the  ID,  where  it  will  then  check  with  the  higher  level  IB  for  information 
pertaining  to  that  user  query.  The  request  to  the  higher  level  domain  IB  does  not  query 
the  higher  level  data  stores  for  new  information,  but  merely  checks  for  Alert  messages 
within  the  system  that  pertain  to  a  particular  role  or  other  mapping  which  we  can 
establish  through  the  rules  that  are  expressed  in  the  Information  Declassifier.  Each  IB, 
upon  receiving  an  ID  request,  will  check  with  a  higher  level  ID  until  the  highest  domain 
level  of  the  system  is  reached.  At  each  domain  level  upon  an  ID  query,  the  information 
broker  will  check  its  Alert  messaging  stores  and  provide  either  a  positive  response  with 
the  information  or  a  negative  response  with  no  data.  This  will  aggregate  downward  until 
the  originating  IB  is  reached.  It  is  then  that  the  IB  will  inject  any  alert  response  data  with 
its  own  query  response  from  domain  level  data  fulfilling  the  user  query.  Information 
markings  are  not  depicted  in  this  flow,  but  the  Information  Broker  is  responsible  for 
adding  appropriate  markings  (at  each  security  level)  for  any  data  that  does  not  already 
contain  markings.  This  will  be  appended  to  the  data  before  the  IB  will  return  a  response 
to  a  user 

In  this  proposed  architecture,  we  have  no  violation  of  BLP-since  we  have  no 
write  down,  nor  do  we  violate  the  RBAC  policy  within  our  classification  domains.  There 
is  no  indirect  means  of  obtaining  information  either,  since  RBAC  ensures  that  we  are  not 
seeing  anything  that  the  Role  does  not  allow  for  in  the  first  place  (nothing  that  the  actor  is 
not  already  entitled  to).  The  Harbormaster  is  entitled  to  examine  information  about  ships 
that  are  entering  his  port.  This  is  merely  a  cause  of  not  being  able  to  see  information 
because  a  higher  classification  level  entity  last  touched  the  data  (where  it  cannot  be 
written  down  *-Property)  and  he  cannot  read  up  to  see  it  (Simple  Security  Property).  As 
long  as  the  system  architecture  is  adhered  to,  the  Information  Declassifier  will  bridge  the 
gap  between  classification  levels  without  creating  covert  channels. 
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Making  these  ehanges  to  the  system  architeeture  requires  several  elements: 
detailed  speeification  of  the  Information  Declassifier  and  its  aetions  (using  RuleML)  via 
domain-specifie  deelassification  polieies  and  rules,  representation  of  query  translations, 
representation  of  system  alert  notifications,  a  revised  definition  of  safety  for  our  new 
architecture,  and  establishment  of  test  cases  that  ensure  the  functionality  of  the  Use  Cases 
and  prevent  the  Misuse  Cases  within  the  re-architected  system.  From  this  we  can  regain 
the  Safety  of  our  information  flows  within  the  system  and  prevent  information  leakage 
between  domains  for  all  future  system  that  adhere  to  our  re-architecting  efforts. 

5.  Conclusion 

This  Use-Case  analysis  and  its  application  demonstrate  the  criticality  of 
architecting  an  information  broker  that  is  integrated  with  the  security  requirements  for 
high-assurance,  while  also  maintaining  the  core  functionality  of  the  system  without 
degradation.  In  general,  we  design  a  system  to  meet  specific  requirements  as  they  are 
provided  by  a  scenario  that  we  wish  to  support.  It  is  from  these  requirements  that  we 
generate  a  desired  policy  that  we  want  to  enact  within  the  system,  and  as  a  result,  we 
select  an  access  control  or  security  model  that  most  closely  approximates  the  intended 
policy.  In  the  policy  that  is  created,  we  expect  to  achieve  a  safety  of  information  flows  by 
using  an  established  security  model.  By  mapping  the  policy  to  the  model  and  then 
extending  our  safety  analysis  from  the  underlying  model  to  the  overarching  security 
policy,  we  can  provide  a  safety  guarantee  for  our  system.  It  is  with  this  safety  guarantee 
in  mind,  that  the  designers  select  an  architecture  and  begin  the  implementation  of  the 
associated  security  policy. 

By  integrating  the  security  requirements  when  deciding  on  an  access  control  model, 
and,  in  this  case,  using  a  mixed  access  control  model,  while  developing  a  rule  set  for 
integration  to  our  security  policy  to  prevent  the  described  Misuse  cases.  The  execution  of 
the  Security  Use  Case  will  originate  with  the  Information  Declassifier  and  the  rules 
associated  with  its  use  as  they  are  mapped  to  the  Use  and  Misuse  Cases  for  the  desired 
system  behaviors  to  maintain  the  safety  property. 
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V.  QUERY  AND  ALERT  MESSAGING 


A.  XML  DATA  SET 

In  Radiant  Alloy,  users  are  able  to  enter  queries  to  the  Information  Broker  that 
correspond  to  information  or  data  required  for  their  role.  A  representation  of  that  data 
found  in  Radiant  Alloy,  can  be  expressed  using  extensible  Markup  Language  (XML).  In 
order  to  examine  how  this  query  ability  could  be  influenced  with  the  use  of  an  ID,  we 
have  created  a  sample  subset  of  XML  data  for  vessel  information  and  alert  messages 
supporting  our  Use-Case  scenario,  for  demonstrating  the  ability  of  the  Use-Case  analysis 
and  ID  rule  generation  to  be  extended  to  other  scenarios. 

Within  the  U.S.  government,  information  markings  are  Defense  Message  System 
(DMS)  General  Service  (GENSER)  message  classifications,  categories  and  markings 
[66].  These  have  been  added  to  the  IB  mechanism,  which  will  actually  perform  the 
formal  access  control  and  apply  classification,  category,  and  dissemination  control 
markings  to  data  as  it  is  pulled  from  repositories  as  appropriate.  In  this  sample,  data  the 
marking  field  has  been  added  and  populated  to  provide  the  ability  to  parse  queries 
appropriate  for  varying  domains  without  the  actual  implementation  of  a  multi-domain, 
replicated  IB.  The  proper  implementation  of  these  marking  requirements  is  to  provide 
interoperability  with  respect  to  security  classifications  and  categories  of  DMS  GENSER 
messaging.  Information  regarding  the  sensitivity  level  and  markings  associated  with 
message  content  needs  to  be  conveyed  to  the  user  requesting  information  from  the 
system.  Additionally,  the  markings  are  required  so  that  access  control  decisions  can  be 
made. 

There  are  generally  two  methods  for  storing  XML  data  in  a  repository.  The  first 
case  is  to  utilize  individual  files  for  each  element  being  described  (i.e.,  a  separate  file  for 
each  vessel).  While  the  second  option  is  to  establish  a  larger,  single  file  with  a  parent 
element  and  list  child  elements  inside  (i.e.,  <VESSELS>  as  the  parent  element  containing 
a  <VESSEL>  tag  for  each  ship).  The  multiple  file  instance  is  more  complex  with  respect 
to  storage  and  querying,  and  the  single  storage  instance  is  merely  a  degenerate  case.  In 
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this  example,  we  used  the  single  doeument  instanee  for  both  the  Alerts  and  Vessels,  as 
the  method  of  storage  does  not  impaet  the  ability  to  exereise  the  rules  of  the  ID. 

1.  Vessel  Information 

The  vessel  information  used  for  this  sample  system  is  based  on  the  Automatic 
Identification  System  (AIS).  AIS  provides  the  means  for  ships  to  electronically  exchange 
data  with  other  nearby  ships  and  Vessel  Traffic  Services  stations.  AIS  was  developed  to 
assist  the  vessel’s  watch  officers  with  a  standardized  information  schema  and  allow 
maritime  authorities  to  track  ships.  The  AIS  uses  a  vessel’s  on-board  navigational 
instruments  to  provide  the  data.  This  system  reliably  transmits  information  about  vessels 
and  ship  tracking  at  fixed  intervals  of  time.  Certain  information,  such  as  the  Maritime 
Mobile  Service  Identity  (MMSI),  Navigation  Status,  Speed,  Latitude,  Longitude, 
Heading,  and  Time  Stamp,  are  transmitted  every  2-10  seconds  (depending  upon  speed) 
while  underway  and  every  3  minutes  while  at  anchor.  Additional  and  less  variable 
information  is  transmitted  every  6  minutes,  to  include  the  IMO  Number,  Call  Sign, 
Length,  Width,  Destination,  and  Estimated  Arrival  Time.  The  XML  data  code  used  in  the 
Vessel.xml  is  shown  in  Listing  1. 


<?xml  version="l . 0"  encoding="UTF-8"  standalone="yes"  ?> 
<VESSELS> 

<TITLE>Vessel  Report</TITLE> 

<MESSAGE> 

<! [CDATA[ 

Listing  of  vessels  resulting  from  your  query. 

]  ]> 

</MESSAGE> 

<!--  Sample  Vessel  used  in  Use  Case:  --> 

<VESSEL> 

<!--  Sample  tracking  data  for  vessels 
—  > 

<NAME_TXT>Name :  </NAME_TXT> 
<NAME>Globalstar7</NAME> 

<MMSI_TXT>MMSI :  </MMSI_TXT> 
<REGISTRY>China</REGISTRY> 

<MILITARY>No</MILITARY> 

<ORIGINATING_PORT>Shanghai</ORIGINATING_PORT> 
<TYPE>Commercial  Vessel</TYPE> 
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<SUB_TYPE>Container  Ship</SUB_TYPE> 

<DEPARTURE>8/28/08  08 : 45</DEPARTURE>  <! —  UTC  /  month/date/year 
hour:minute  --> 

<!--  AIS  sends  the  following  data  every  2-10  seconds  while  underway 
depending  on  speed,  and  every  3  minutes  while  at  anchor 

— > 

<MMSI>412159177</MMSI>  <!--  Maritime  Mobile  Service  Identity 

412,  413  China--> 

<NAV_STATUS>Under  Way  Using  Engines</NAV_STATUS>  <!--  At  Anchor, 
Under  Way,  etc.  --> 

<RATE_OF_TURN>0</RATE_OF_TURN>  <! —  Right  or  Left,  0-720  degrees 
per  minute  --> 

<SPEED_OVER_GROUND>10 . 2  Knots</SPEED_OVER_GROUND>  <! —  0  to  102 
Knots,  0.1  increments  — > 

<POSITION_ACCURACY>3  Meters</POSITION_ACCURACY> 

<LATITUDE>27 . 147145</LATITUDE> 

<LONGITUDE>-128 . 342285</LONGITUDE> 

<COURSE_OVER_GROUND></COURSE_OVER_GROUND>  <! —  relative  to  true  N 
to  0.1  degree  --> 

<TRUE_HEADING>27</TRUE_HEADING>  <! —  0  to  359  degrees  from 
gyro  compass  --> 

<TIME_STAMP></TIME_STAMP>  <! —  UTC  time  stamp  for  data  — > 

<!--  AIS  broadcasts  the  following  data  every  6  minutes 
— > 

<IMO_NUMBER>IMO  12345 67</IMO_NUMBER>  <! —  #  unchanged  upon 
transfer  of  registry  — > 

<RADIO_CALL_SIGN>G7CSl</RADIO_CALL_SIGN>  <! —  up  to  seven 
characters  --> 

<TYPE_POSITIONING>LORAN-C</TYPE_POSITIONING>  <! —  GPS,  DGPS, 
LORAN-C  — > 

<LENGTH>200</LENGTH> 

<WIDTH>25</WIDTH> 

<DRAUGHT>25</DRAUGHT> 

<DESTINATION_PORT>San  Diego</DESTINATION_PORT>  <! —  Max  20 
characters  --> 

<EST_ARRIVAL>10/l/08  13 : 00</EST_ARRIVAL>  <! —  UTC  / 
month/date/year  hour: minute  — > 

<CLASSIFICATION>Top  Secret</CLASSIFICATION> 
<ALERT_PRESENT>Yes</ALERT_PRESENT> 

</VESSEL>  <! —  — > 

<!--  Sample  Vessel  used  in  Use  Case:  — > 

<VESSEL> 

<!--  Sample  tracking  data  for  vessels 
— > 

<NAME_TXT>Name :  </NAME_TXT> 

<NAME>USS  ANTIETAM</NAME> 

<MMSI_TXT>MMSI :  </MMSI_TXT> 

<REGISTRY>USA</REGISTRY> 

<MILITARY>YES</MILITARY> 

<ORIGINATING_PORT>San  Diego</ORIGINATING_PORT> 

<TYPE>Military  Vessel</TYPE> 


85 


<SUB_TYPE>CG-54</SUB_TYPE> 

<DEPARTURE>0/0/00  00 : 00</DEPARTURE>  <! —  UTC  /  month/date/year 
hour:minute  --> 

<!--  AIS  sends  the  following  data  every  2-10  seconds  while  underway 
depending  on  speed,  and  every  3  minutes  while  at  anchor 

— > 

<MMSI>36677900</MMSI>  <!--  Maritime  Mobile  Service  Identity  366 

U.  S  .  — > 

<NAV_STATUS>Under  Way  Using  Engines</NAV_STATUS>  <!--  At  Anchor, 
Under  Way,  etc.  --> 

<RATE_OF_TURN>Right  5</RATE_OF_TURN>  <! —  Right  or  Left,  0-720 
degrees  per  minute  --> 

<SPEED_OVER_GROUND>25 . 7  Knots</SPEED_OVER_GROUND>  <! —  0  to  102 
Knots,  0.1  increments  — > 

<POSITION_ACCURACY>3  Meters</POSITION_ACCURACY> 

<LATITUDE>25 . 0 9554 9</LATITUDE> 

<LONGITUDE>-137 . 625732</LONGITUDE> 

<COURSE_OVER_GROUND>57 . 6</COURSE_OVER_GROUND>  <! —  relative  to 
true  N  to  0.1  degree  — > 

<TRUE_HEADING>57 . 8</TRUE_HEADING>  <! —  0  to  359  degrees 
from  gyro  compass  --> 

<TIME_STAMP>9/28/08  14 : 17</TIME_STAMP>  <! —  UTC  time  stamp  for 
data  --> 

<!--  AIS  broadcasts  the  following  data  every  6  minutes 
— > 

<IMO_NUMBER>IMO  7 65432 1</ IMO_NUMBER>  <! —  #  unchanged  upon 
transfer  of  registry  — > 

<RADIO_CALL_SIGN>CGA2X54</RADIO_CALL_SIGN>  <! —  up  to  seven 
characters  --> 

<TYPE_POSITIONING>LORAN-C</TYPE_POSITIONING>  <! —  GPS,  DGPS, 
LORAN-C  — > 

<LENGTH>250</LENGTH> 

<WIDTH>32</WIDTH> 

<DRAUGHT>30</DRAUGHT> 

<DESTINATION_PORT>Not  Reported</DESTINATION_PORT>  <! —  Max  20 
characters  --> 

<EST_ARRIVAL>0/0/00  0 0 : 0 0</EST_ARRIVAL>  <! —  UTC  /  month/date/year 
hour: minute  --> 

<CLASSIFICATION>Unclassified</CLASSIFICATION> 

<ALERT_PRESENT>No</ALERT_PRESENT> 

</VESSEL>  <! —  — > 

<VESSEL> 

<!--  Sample  tracking  data  for  vessels 

— > 

<NAME_TXT>Name :  </NAME_TXT> 

<NAME>Globalstar2</NAME> 

<MMSI_TXT>MMSI :  </MMSI_TXT> 

<REGISTRY>China</REGISTRY> 

<MILITARY>No</MILITARY> 

<ORIGINATING_PORT>Shanghai</ORIGINATING_PORT> 

<TYPE>Commercial  Vessel</TYPE> 
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<SUB_TYPE>Container  Ship</SUB_TYPE> 

<DEPARTURE>9/15/08  02 : 45</DEPARTURE> 

<!--  UTC  /  month/date/year  hour:minute  --> 

<!--  AIS  sends  the  following  data  every  2-10  seconds  while  underway 
depending  on  speed,  and  every  3  minutes  while  at  anchor 

> 

<MMSI>412159197</MMSI> 

<!--  Maritime  Mobile  Service  Identity  412,  413  China--> 
<NAV_STATUS>Under  Way  Using  Engines</NAV_STATUS> 

<!--  At  Anchor,  Under  Way,  etc.  — > 

<RATE_OF_TURN>  0  < / RATE_OF_TURN> 

<!--  Right  or  Left,  0-720  degrees  per  minute  --> 
<SPEED_0VER_GR0UND>11 . 2  Knots</SPEED_OVER_GROUND> 

<!--  0  to  102  Knots,  0.1  increments  — > 

<POSITION_ACCURACY>3  Meters</POSITION_ACCURACY> 

<LATITUDE>47 . 147145</LATITUDE> 

<LONGITUDE>-121 . 342285</LONGITUDE> 
<COURSE_OVER_GROUND></COURSE_OVER_GROUND> 

<!--  relative  to  true  N  to  0.1  degree  --> 

<TRUE_HEADING>  6  7  < / TRUE_HEADING> 

<!--  0  to  359  degrees  from  gyro  compass  --> 

<TIME_STAMP>9/28/08  0 9 : 4 9</TIME_STAMP> 

<!--  UTC  time  stamp  for  data  — > 

<!--  AIS  broadcasts  the  following  data  every  6  minutes 

> 

< IMO_NUMBER> IMO  1234561</ IMO_NUMBER> 

<!--  #  unchanged  upon  transfer  of  registry  --> 
<RADIO_CALL_SIGN>G2CSl</RADIO_CALL_SIGN> 

<!--  up  to  seven  characters  — > 
<TYPE_POSITIONING>LORAN-C</TYPE_POSITIONING> 

<! —  GPS,  DGPS,  LORAN-C  — > 

<LENGTH>200</LENGTH> 

<WIDTH>25</WIDTH> 

<DRAUGHT>25</DRAUGHT> 

<DESTINATION_PORT>San  Diego</DESTINATION_PORT> 

<!--  Max  20  characters  --> 

<EST_ARRIVAL>10/2/08  15 : 00</EST_ARRIVAL> 

<!--  UTC  /  month/date/year  hour: minute  --> 

<CLASSIFICATION>Unclassified</CLASSIFICATION> 

<ALERT_PRESENT>No</ALERT_PRESENT> 

</VESSEL> 

<! —  — > 

<VESSEL> 

<!--  Sample  tracking  data  for  vessels 

> 

<NAME_TXT>Name :  </NAME_TXT> 

<NAME>Globalstar8</NAME> 

<MMSI_TXT>MMSI :  </MMSI_TXT> 

<REGISTRY>China</REGISTRY> 

<MILITARY>No</MILITARY> 

<ORIGINATING_PORT>San  Diego</ORIGINATING_PORT> 

<TYPE>Commercial  Vessel</TYPE> 
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<SUB_TYPE>Container  Ship</SUB_TYPE> 

<DEPARTURE>9/27/08  21 : 15</DEPARTURE> 

<!--  UTC  /  month/date/year  hour:minute  --> 

<!--  AIS  sends  the  following  data  every  2-10  seconds  while  underway 
depending  on  speed,  and  every  3  minutes  while  at  anchor 

— > 

<MMSI>412159178</MMSI> 

<!--  Maritime  Mobile  Service  Identity  412,  413  China--> 
<NAV_STATUS>Under  Way  Using  Engines</NAV_STATUS> 

<!--  At  Anchor,  Under  Way,  etc.  — > 

<RATE_OF_TURN>  0  < / RATE_OF_TURN> 

<!--  Right  or  Left,  0-720  degrees  per  minute  --> 
<SPEED_OVER_GROUND>15 . 6  Knots</SPEED_OVER_GROUND> 

<!--  0  to  102  Knots,  0.1  increments  — > 

<POSITION_ACCURACY>3  Meters</POSITION_ACCURACY> 

<LATITUDE>37 . 147145</LATITUDE> 

<LONGITUDE>-18 . 342285</LONGITUDE> 
<COURSE_OVER_GROUND></COURSE_OVER_GROUND> 

<!--  relative  to  true  N  to  0.1  degree  --> 

<TRUE_HEADING>  9  8  < / TRUE_HEADING> 

<!--  0  to  359  degrees  from  gyro  compass  --> 

<TIME_STAMP>9/28/08  14 : 45</TIME_STAMP> 

<!--  UTC  time  stamp  for  data  — > 

<!--  AIS  broadcasts  the  following  data  every  6  minutes 

— > 

< IMO_NUMBER> IMO  1234568</ IMO_NUMBER> 

<!--  #  unchanged  upon  transfer  of  registry  --> 
<RADIO_CALL_SIGN>G8CSl</RADIO_CALL_SIGN> 

<!--  up  to  seven  characters  — > 
<TYPE_POSITIONING>LORAN-C</TYPE_POSITIONING> 

<! —  GPS,  DGPS,  LORAN-C  — > 

<LENGTH>200</LENGTH> 

<WIDTH>25</WIDTH> 

<DRAUGHT>25</DRAUGHT> 

<DESTINATION_PORT>Oakland</DESTINATION_PORT> 

<!--  Max  20  characters  --> 

<EST_ARRIVAL>10/5/08  19 : 30</EST_ARRIVAL> 

<!--  UTC  /  month/date/year  hour: minute  --> 

<CLASSIFICATION>Unclassified</CLASSIFICATION> 

<ALERT_PRESENT>Yes</ALERT_PRESENT> 

</VESSEL> 

<! —  — > 

</VESSELS> 

Listing  1.  XML  Code  for  Vessels.xml 


This  code  represents  a  small-scale  sample  of  the  type  of  data  that  might  be 
available  in  a  production  level  Radiant  Alloy  system  that  is  connected  into  real-time 
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repositories  and  reporting  systems  based  on  the  National  Information  Exchange  Model 
(NIEM)  [9].  By  using  this  sample  XML  code  as  a  foundation,  we  can  test  a  live  query 
based  request  for  data  and  the  integration  of  the  ID  used  in  the  re-architecting  of  our 
system  with  existing  alerts. 

1.  Alert  Messages 

System  Alert  Notifications  are  added  to  the  replicated  domain-level  IBs  as  the 
notifications  are  archived  and  retrieved.  Alert  Notification  messages  are  based  on  the 
standard  maritime  Advance  Notice  of  Arrival  (ANOA)  and  use  the  XML-based  Maritime 
Information  Exchange  Model  (MIEM)  [5].  The  alert  includes  fields  from  a  standard 
Vessel  Activity  Report  (VAR)  to  show  details  such  as  identification,  kinematics,  and  port 
history,  as  well  as  the  specific  instructions  pertaining  to  the  alert.  In  our  scenario,  the 
EWO  processes  an  Alert  Notification  about  the  GlobalstarV,  as  he  or  she  updates  some 
part  of  the  VAR  data  for  that  vessel,  thus  causing  the  VAR  to  “disappear”  from  the  lower 
level  (Unclassified)  view  in  the  system. 

These  Alert  messages  become  a  critical  piece  of  the  Use-Case  scenario  that  was 
presented.  As  vessels  are  processed  in  the  system  as  Vessels  of  Interest  (VOI),  alerts  are 
generated.  These  alerts  are  processed  at  whichever  classification  level  they  originate  from 
(e.g.,  Top  Secret),  and  the  role  of  the  IB  will  be  extended  to  both  distribute  and  query 
these  alerts  as  the  system  is  used.  Since  each  alert  contains  information  pertaining  to  a 
specific  vessel,  port,  and  time  group,  we  can  effectively  query  the  XML-based 
information  in  the  same  manner  as  we  would  any  other  data.  This  allows  a  seamless 
integration  with  our  ID  and  our  domain-level  IBs  to  process  queries  based  on  Vessel  and 
Alert  Message  details.  Our  Use-Case  scenario  dictates  that  valid  Alert  Messages  will  be 
generated  to  notify  ports  or  facilities  of  pertinent  information.  These  Alerts  will  include 
the  following: 

•  To  Information  (a  Port  or  a  Role  can  be  used  in  this  field) 

•  Date  Time  Group  (DTG)  of  the  Alert  generation 

•  Suspense  for  action  on  the  Alert 
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•  special  instructions  or  Comments  regarding  the  message 

•  Vessel  of  Interest  (VOI)  information 

As  the  Electronic  Warfare  Officer  (EWO)  performs  his  duties,  he  is  responsible  for  the 
generation  of  Alert  Messages.  These  messages  are  intended  to  facilitate  port  security  and 
homeland  defense,  and  the  EWO  has  the  responsibility  of  transmitting  the  Alert  Message 
through  the  system.  Listing  2  shows  a  sample  alert  message  XML  file  was  generated  for 
the  High  Level  Alert  Use-Case  scenario. 


<?xml  version="l . 0"  encoding="utf-8 "  ?> 
<?xml-stylesheet  type="text/css"  href="alert . css"  ?> 
<?xml-stylesheet  type="text/css"  href="vessels . css"  ?> 


<ALERTS> 

<TITLE>ALERT  Notif ication</TITLE> 

<MESSAGE> 

<! [CDATA[ 

Alert  for  a  Vessel  of  Interest  (VOI) . 

]  ]> 

</MESSAGE> 

<!--  Alert  format  for  Use  Gase:  --> 

<ALERT> 

<ALERT_TO>San  Diego</ALERT_TO> 

<ALERT_DTG>9/28/08  05 : 0 0</ALERT_DTG> 

<SUSPENSE>10/01/08  2 3 : 5 9</ SUSPENSE> 

<GOMMENTS> 

<! [GDATA[ 

VOI  --  notify  local  GG  Office  @  (619)  867-5309  upon  arrival  and 

inspect  cargo  with  CG  Duty  Officer 

]  ]> 

</GOMMENTS> 

<VESSEL> 

<!--  Sample  tracking  data  for  vessels 
--> 

<NAME_TXT>Name :  </NAME_TXT> 

<NAME>Globalstar7</NAME> 

<MMS1_TXT>MMS1 :  </MMSl_TXT> 

<REGlSTRY>Ghina</REGlSTRY> 

<MlLlTARY>No</MlLlTARY> 

<ORlGlNATlNG_PORT>Shanghai</ORlGlNATlNG_PORT> 

<TYPE>Commercial  Vessel</TYPE> 

<SUB_TYPE>Gontainer  Ship</SUB_TYPE> 

<DEPARTURE>8/28/08  08 : 45</DEPARTURE>  <!--  UTC  /  month/date/year 
houriminute  --> 

<!--  AIS  sends  the  following  data  every  2-10  seconds  while 

underway 
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depending  on  speed,  and  every  3  minutes  while  at  anchor 

--> 

<MMSI>412159177</MMSI>  <! —  Maritime  Mobile  Service  Identity  412, 

413  China--> 

<NAV_STATUS>Under  Way  Using  Engines</NAV_STATUS>  <!--  At  Anchor, 
Under  Way,  etc.  --> 

<RATE_OF_TURN>0</RATE_OF_TURN>  <!--  Right  or  Left,  0-720  degrees 
per  minute  --> 

<SPEED_OVER_GROUND>10.2  Knots</ SPEED_OVER_GROUND>  <!--  0  to  102 
Knots,  0.1  increments  --> 

<POSITION_ACCURACY>3  Meters</POSITION_ACCURACY> 

<LATITUDE>27 . 1 4 7 1 4 5</LATITUDE> 

<LONGITUDE>-128 . 3422 85</LONGITUDE> 

<GOURSE_OVER_GROUND></GOURSE_OVER_GROUND>  <!--  relative  to  true  N 
to  0.1  degree  --> 

<TRUE_HEADING>27</TRUE_HEADING>  <!--  0  to  359  degrees  from 
gyro  compass  --> 

<TIME_STAMP></TIME_STAMP>  <!--  UTG  time  stamp  for  data  --> 

<!--  AIS  broadcasts  the  following  data  every  6  minutes 
--> 

<IMO_NUMBER>IMO  1234567</IMO_NUMBER>  <!--  #  unchanged  upon 

transfer  of  registry  --> 

<RADIO_CALL_SIGN>G7CSl</RADIO_CALL_SIGN>  <!--  up  to  seven 

characters  --> 

<TYPE_POSITIONING>LORAN-G</TYPE_POSITIONING>  <!--  GPS,  DGPS, 

LORAN-G  --> 

<LENGTH>200</LENGTH> 

<WIDTH>25</WIDTH> 

<DRAUGHT>25</DRAUGHT> 

<DESTINATION_PORT>San  Diego</DESTINATION_PORT>  <!--  Max  20 
characters  --> 

<EST_ARRIVAL>10/l/08  13 : 00</EST_ARRIVAL>  <!--  UTG  / 
month/date/year  houriminute  --> 

<CLASSIFIGATION>Top  Secret</GLASSIFIGATION> 
<ALERT_PRESENT>Yes</ALERT_PRESENT> 

</VESSEL>  <!--  --> 

</ALERT> 

<!--  Alert  format  for  Use  Gase :  --> 

<ALERT> 

<ALERT_TO>Oakland</ALERT_TO> 

<ALERT_DTG>10/02/08  05 : 0 0</ALERT_DTG> 

<SUSPENSE>10/ 06/08  2 3 : 5 9</ SUSPENSE> 

<GOMMENTS> 

<! [CDATA[ 

VOI  --  call  Dr.  Falken  from  Protovision  at  555-8632,  also  alert 
INS  and  local  GG 

]  ]> 

</ COMMENT S> 

<VESSEL> 

<!--  Globalstar8 

<NAME_TXT>Name :  </NAME_TXT> 

<NAME>Globalstar8</NAME> 

<MMSI_TXT>MMSI :  </MMSI_TXT> 

<REGISTRY>China</REGISTRY> 

<MILITARY>No</MILITARY> 
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<ORIGINATING_PORT>San  Diego</ORIGINATING_PORT> 

<TYPE>Commercial  Vessel</TYPE> 

<SUB_TYPE>Container  Ship</SUB_TYPE> 

<DEPARTURE>9/27/08  21: 15</DEPARTURE> 

<!--  UTG  /  month/date/year  houriminute  --> 

<!--  AIS  sends  the  following  data  every  2-10  seconds  while  underway 
depending  on  speed,  and  every  3  minutes  while  at  anchor 

--> 

<MMSi>412159178</MMSi> 

<!--  Maritime  Mobile  Service  identity  412,  413  Ghina--> 
<NAV_STATUS>Under  Way  Using  Engines</NAV_STATUS> 

<!--  At  Anchor,  Under  Way,  etc.  --> 

<RATE_OF_TURN>0</RATE_OF_TURN> 

<!--  Right  or  Left,  0-720  degrees  per  minute  --> 
<SPEED_OVER_GROUND>15 . 6  Knots</ SPEED_OVER_GROUND> 

<!--  0  to  102  Knots,  0.1  increments  --> 

<POSiTiON_ACCURAGY>3  Meters</POSiTiON_ACCURACY> 

<LATiTUDE>37 . 1 4 7 1 4 5</LATiTUDE> 

<LONGiTUDE>-18 . 3422 85</LONGiTUDE> 
<COURSE_OVER_GROUND></COURSE_OVER_GROUND> 

<!--  relative  to  true  N  to  0.1  degree  --> 
<TRUE_HEADiNG>98</TRUE_HEADiNG> 

<!--  0  to  359  degrees  from  gyro  compass  --> 

<TiME_STAMP>9/28/08  14 : 45</TiME_STAMP> 

<!--  UTG  time  stamp  for  data  --> 

<!--  AiS  broadcasts  the  following  data  every  6  minutes 

--> 

< iMO_NUMBER> IMO  1234568</ iMO_NUMBER> 

<!--  #  unchanged  upon  transfer  of  registry  --> 
<RADiO_CALL_SiGN>G8GSl</RADiO_CALL_SiGN> 

<!--  up  to  seven  characters  --> 
<TYPE_POSiTiONiNG>LORAN-G</TYPE_POSiTiONiNG> 

<!--  GPS,  DGPS,  LORAN-G  --> 

<LENGTH>200</LENGTH> 

<WiDTH>25</WiDTH> 

<  DRAUGHT  >  2  5  < / DRAUGHT  > 

<DESTiNATiON_PORT>Oakland</DESTiNATiON_PORT> 

<!--  Max  20  characters  --> 

<EST_ARRiVAL>10/5/08  19 : 30</EST_ARRiVAL> 

<!--  UTG  /  month/date/year  houriminute  --> 

<GLASSiFiCATiON>Unclassified</CLASSiFiGATiON> 

<ALERT_PRESENT>Yes</ALERT_PRESENT> 

</VESSEL> 

<!--  --> 

</ALERT> 

</ALERTS> 

Listing  2.  XML  Code  for  Alerts.xml 


Despite  having  only  two  alerts  in  the  sample  data  store,  we  can  still  show  the 
ability  to  parse  through  the  data  for  alerts  that  pertain  to  specific  locations  and  provide  a 
basis  for  the  testing  of  our  query  engine  and  the  resultant  ID  rules  that  are  created  to 
specify  our  security  policy.  In  our  High  Level  Alert  Use-Case  scenario,  we  find  that  the 
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EWO  is  at  a  higher  classification  level  (i.e.,  Top  Secret),  than  the  Harbormaster  to  whom 
the  Alert  Message  is  intended.  Since  the  EWO  is  operating  in  a  different  domain  than  the 
Harbormaster,  when  he  touches  information  in  the  system,  by  marking  the  Globalstar?  as 
a  VOI,  he  effectively  prevents  all  lower  classification  users  from  seeing  this  track  (due  to 
the  tranquilty  property  of  BEP).  This  is  where  the  unintended  creation  of  information 
leakage  arises  when  the  Harbormaster  becomes  alerted  to  the  presence  of  a  ship  in  the 
system  that  he  cannot  access  information  pertaining  to  from  his  resultant  queries. 

B.  QUERIES 

Several  methods  exist  for  generating  queries  and  controlling  access  to  data  stores 
based  on  XML.  These  include  XQuery  and  XPath,  developed  by  the  W3C  [67]. 
XMLQuery,  however,  does  not  allow  the  modification  of  data  and  subsequent  saving  of 
the  modified  information  back  into  the  data  store  and  is  a  deprecated  version  of  XPath. 
User  queries  are  a  standard  and  integral  service  of  the  IB  and  are  generated  using  Xpath. 
Each  request  for  data  (i.e.,  query)  processed  by  the  IB  is  first  checked  for  permissions  by 
the  Policy  Decision  Point  (PDP)  service,  then  passed  via  a  service  call  to  the  ID  service 
associated  with  that  classification  level.  The  IB  then  begins  execution  of  the  query  itself 
but  must  wait  for  a  positive  or  negative  response  from  the  ID  service  before  returning 
results  to  the  user.  Valid  queries  can  be  performed  on  any  field  available  from  an  Alert 
Message  or  within  a  VAR.  A  sample  Xpath  query  for  the  San  Diego  Harbormaster 
requesting  a  Destination  Port  query  is  shown  in  Listing  3. 

/VESSELS/VESSEL/DESTINATION_PORT [text () ='San  Diego' ] 

Listing  3.  Xpath  Query  for  San  Diego  Harbormaster  using  Destination  Port 

Integral  to  this  query  are  the  attributes  for  the  user  (role,  location,  security  level, 
and  time  stamp)  that  are  also  passed  with  the  query  for  use  by  both  the  IB  and  ID 
services.  These  attached  attributes  are  critical  to  the  IB’s  response  since  the  XPath  query 
that  is  used  for  the  EWO  (Listing  4)  is  identical  to  the  query  from  the  Harbormaster. 

/VESSELS/VESSEL/DESTINATION_PORT [text  0  =  'San  Diego' ] 

Listing  4.  Xpath  Query  for  EWO  using  Destination  Port  of  San  Diego 
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The  differences  in  the  query  return  data  are  from  the  IB’s  use  of  those  additional 
attributes  attached  to  the  initial  query.  Figure  22  shows  the  XML  data  present  for  all 
vessels  in  the  system  and  then  the  expected  results  from  San  Diego  destination  port 
queries  for  both  the  Harbormaster  and  the  EWO. 


^  Sample  Use-Case  System  Results  -  Internet  Ej^lorer  provided  by  Dell 

V  ^  http;//localhGst;60072/WebQu  ^ 

X  '  Google  P 

^  'iSr  Sample  Use-Case  System  Re... 

^  ^  0  ^  ^  [3^  Page  ^  Tools  ^ 

Querj^  for  All  Vessels 


Name  Orieinatinff  Port 


IH 

10/1/08  13:00  41215917?  Globalstar?  Shanghai 

0/0/00  00:00  36677900  USS  ANTIETAM  San  Diego 

10/2/08  15:00  412159197  Globalstar2  Shanghai 

10/5/08  1 9:30  412159178  Global5tar8  San  Diego 


Bestmation  Port  Est  Arrival  MMSI 


San  Diego 
Not  Reported 
San  Diego 
Oakland 


HjVI  Query  for  v  essels  with  Destination  of  ^  San  Diego^ 


Bestination  Port  Est  Ariival  MMSI  Name  Oiiginatmg^Port 


San  Diego 


10/2/08 

15:00 


412159197  Globalstar2 


Shanghai 


EWQ  Queiy  for  Vessels  with  Destination  of  ^'San  Diego^' 


Bestination  Port  Est  Arrival  MMSI  Name  Originating  Port 


San  Diego  10/1/08  13:00  412159177  Globalstar?  Shanghai 

San  Diego  10/2/08  15:00  412159197  Global5tar2  Shanghai 


Figure  22.  Expected  XPath  Query  Results  by  Role 

In  our  High  Level  Alert  Use-Case  scenario,  valid  queries  can  be  performed  on  any 
field  available  from  an  Alert  Message  or  within  Vessel  details.  The  data  set  that  the 
system  returns  must  be  restricted  based  upon  Role  permission  for  each  of  our  actors  in 
the  scenario.  In  this  case,  the  query  and  resultant  data  must  include  the  Harbormaster’s 
port  (either  Origination  or  Destination)  for  details  to  be  returned  by  the  IB  and  ID.  This 
will  prevent  a  Harbormaster  from  just  querying  the  system  to  get  information  about 
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vessels  from  the  system  that  do  not  directly  pertain  to  his  role  (at  his  location)  and  his 
direct  performance  of  duty.  But,  he  should  be  entitled  to  know  information  about  ships 
arriving  or  departing  from  his  location,  since  this  is  a  key  responsibility  of  his  job. 
Additionally,  the  Harbormaster  should  be  able  to  query  the  system  for  the  presence  of 
Alert  Messages  that  pertain  to  his  role.  These  aspects  are  areas  that  must  be  enforced 
using  the  IB,  but  can  only  be  done  as  a  result  of  our  re-architecting  through  the  addition 
of  an  ID  and  its  rule  processing. 

This  result  is  reflective  of  a  standard  query  to  the  system  and  can  be  extended  as 
necessary  to  support  other  scenarios.  The  XPath  query  can  be  used  on  both  standard 
vessel  data  that  is  present  in  the  system,  as  well  as  for  Alert  Messages  that  are  present. 
Listing  5  depicts  a  sample  Xpath  query  for  Alert  Messaging  for  the  port  of  San  Diego. 

/ALERTS/ALERT/DESTINATION_PORT [text () ='San  Diego' ] 

Listing  5.  Xpath  Alert  Messaging  Query  for  San  Diego  Harbormaster 

While  Listing  6  depicts  the  query  that  would  be  executed  by  the  EWO  for  Alerts 
present  at  the  TS  level.  This  query  would  return  all  alerts  present  at  his  security  level, 
since  we  are  not  restricting  the  EWO’s  access  because  of  his  role. 

/ALERTS /ALERT 

Listing  6.  Xpath  Alert  Messaging  Query  for  EWO 
The  expected  results  of  both  of  these  Alert  Messaging  queries  are  shown  in  Figure  23. 
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Sample  Use-Case  System  Results  -  Internet  Explorer  provided  by  □ 

http://localhost:60072/WebQuery/Defai 

X  Google  1 

^  ^  Sample  Use-Case  System  Results 

^  0  ®  [^Page  Tools  '■ 

EWO  Querj’  for  Alerts 


AlertTo 

Comments 

Suspense 

VOI  —  noti^'  local 

CG  Office  ® 

San 

(619)  867-5309 

10/01/08 

Diego 

upon  arriv'al  and 

23:59 

inspect  cargo  with 
CG  Dut>'  Officer 

VOI  -  call  Dr. 
Falken  from 

Oakland  Proto\ision  at  555- 
8632,  also  alert 
INS  and  local  CG 


10/06/08 

23:59 


Vessel  of  Interest 


Name:  GlobalstarTMMSI; 
ChinaNoShanghaiCommercial  VesselContainer 
Ship8/28/08  08:45412159177Under  Way  Using 
EnginesOlO.2  Knots3  Meters27.147145- 
128.34228527IMO  1234567G7CS1LORAN- 
C2002525San  Diego  10/1/08  13:00TS/SCIYes 

Name:  Globalstar8M\lSI:  ChinaNoSan 
DiegoCommercial  VesselContainer  Ship9/27/08 
2 1 :1 54 12 1 59 1 78Under  Way  Using  EngbesO  15.6 
Knots3  Meters37. 147145-1 8.342285989.'^8/08 
14:4  5MO  1234568G8CS1LORAN- 
C20025250aldandl  0/5/08  1 9:30UnclassifiedYes 


HM  Querj’  for  ’’Sau  Diego”  Alerts 


AlertTo  Conunents  Suspense 


VOI  --  noti^^  local 
CG  Office  @(619) 

San  867-5309  upon  1 0/0 1  /O  8 

Diego  arm^al  and  mspect  23:59 
cargo  Vh-rtli  CG  Dut>^ 

Officer 


Vessel  of  Interest 


Name:  Globalstar7MMSI: 
ChinaNoShanghaiCommercial  VesselContainer 
Ship8/28/08  08:454 121 59 177Under  Way  Using 
EngmesOlO.2  Knots3  Meters27.147145- 
128.34228527rMO  1234567G7CS1LORAN- 
C2002525San  Diego  10/1/08  13:00TS/SCIYes 


@  Internet  |  Protected  Mode;  On 


Figure  23.  Expected  XPath  Query  Alert  Messaging  Results  by  Role 


As  an  additional  query  method  and  to  better  support  a  web-enable  test  framework 
for  query  integration,  we  chose  to  utilize  Language  Integrated  Query  (LINQ)  and 
integrate  the  queries  using  Visual  Basic.  It  includes  query,  set,  and  transform  operations 
via  integrated  library  functions  for  data.  LINQ  to  XML  takes  advantage  of  standard  query 
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operators  and  adds  query  extensions  specific  to  XML,  as  well  as  offering  integration  with 
RDF  format  data.  Either  of  these  query  methods  (XPath  or  LINQ)  can  exist  in  Radiant 
Alloy.  The  web  page  version  could  easily  be  modified  to  allow  for  easier  manipulation  of 
queries  and  access  to  the  data,  but  in  this  example  we  relied  on  hard-coding  of  queries 
and  singular  executions  to  show  that  the  query  system  is  operational.  A  sample  of  the 
query  system  using  LINQ  is  shown  in  Listing  7. 


Imports  System . Xml . Linq 

Partial  Class  _Default 

Inherits  System . Web . UI . Page 
Private  xmlDocument  As  XDocument 

Protected  Overrides  Sub  OnLoad(ByVal  e  As  System . EventArgs ) 

MyBase . OnLoad (e) 

LoadXMLDocument ( ) 

GridViewl . DataSource  =  DescendantsQueryl ( ) 

GridViewl . DataBind ( ) 

GridView2 . DataSource  =  DescendantsQueryS ( ) 

GridView2 . DataBind ( ) 

Dim  vesselListl  As  XDocument  = 

XDocument . Load (MapPath ( "vessels . xml" ) ) 

Dim  alertListl  As  XDocument  = 

XDocument . Load (MapPath ( "alerts . xml" ) ) 

GridViewS . DataSource  =  From  VESSEL  In  vesselListl ... <VESSEL> 
Where  VESSEL . <ORIGINATING_PORT> . Value  =  "San  Diego"  And 
VESSEL. <CLASSIFICATION>. Value  =  "Unclassified"  Select  Name  = 

VESSEL. <NAME>. Value,  MMSI  =  VESSEL . <MMSI> . Value ,  Est_Arrival  = 

VESSEL . <EST_ARRIVAL> .Value,  Originating_Port  = 

VESSEL. <ORIGINATING_PORT>. Value,  Destination_Port  = 

VESSEL . <DESTINATION_PORT> . Value 
GridViewS . DataBind ( ) 

GridViewS . DataSource  =  From  VESSEL  In  vesselListl ... <VESSEL> 
Where  VESSEL . <DESTINATION_PORT> . Value  =  "San  Diego"  And 
(VESSEL. <CLASSIFICATION>. Value  =  "Top  Secret"  Or 
VESSEL. <CLASSIFICATION>. Value  =  "Unclassified")  Select  Name  = 

VESSEL. <NAME>. Value,  MMSI  =  VESSEL . <MMSI> . Value ,  Est_Arrival  = 

VESSEL. <EST_ARRIVAL>. Value,  Originating_Port  = 

VESSEL. <ORIGINATING_PORT>. Value,  Destination_Port  = 

VESSEL . <DESTINATION_PORT> . Value 
GridViewS . DataBind ( ) 

GridView4 . DataSource  =  From  ALERT  In  alertListl ... <ALERT> 

Select  Alert_To  =  ALERT . <ALERT_TO> . Value,  Suspense  = 

ALERT. <SUSPENSE>. Value,  Comments  =  ALERT . <COMMENTS> .Value, 
Vessel_of_Interest  =  ALERT . <VESSEL> .Value 
GridView4 . DataBind ( ) 

GridViewG . DataSource  =  From  ALERT  In  alertListl ... <ALERT>  Where 
ALERT . <ALERT_TO> .Value  =  "San  Diego"  And 
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( ALERT. <VESSEL>.<ORIGINATING_PORT>. Value  =  "San  Diego"  Or 
ALERT. <VESSEL>.<DESTINATION_PORT>. Value  =  "San  Diego")  Select  Alert_To 
=  ALERT . <ALERT_TO> . Value,  Suspense  =  ALERT . <SUSPENSE> . Value,  Comments  = 
ALERT .<COMMENTS>. Value,  Vessel_of_lnterest  =  (ALERT . <VESSEL> . Value) 
GridViewG . DataBind ( ) 

''Demonstrates  traversing  XML  in  a  LINQ  query. 

'For  Each  x  In  xmlDocument . . . <VESSELS> . <NAME> 

End  Sub 

Public  Sub  LoadXMLDocument ( ) 

xmlDocument  =  XDocument . Load (MapPath ( "vessels . xml" ) ) 

End  Sub 

'  '  '  <summary> 

'''  Query  the  vessels  descendants  for  details  using  Element. 

' ' '  </summary> 

'''  <returns>Ob j ect</returns> 

Public  Function  DescendantsQueryl ( )  As  Object 

Return  From  VESSEL  In  xmlDocument ... <VESSEL>  Select  Name  = 
VESSEL. <NAME>. Value,  MMSl  =  VESSEL . <MMS1> . Value ,  Est_Arrival  = 

VESSEL. <EST_ARR1VAL>. Value,  Originating_Port  = 

VESSEL. <0R1G1NAT1NG_P0RT>. Value,  Destination_Port  = 

VESSEL . <DEST1NAT10N_P0RT> . Value 

End  Function 

' ' '  <summary> 

'''  Query  the  vessels  descendants  for  details  using  Element. 

' ' '  </summary> 

'''  <returns>Ob j ect</returns> 

Public  Function  DescendantsQueryS ( )  As  Object 

Return  From  VESSEL  In  xmlDocument ... <VESSEL>  Where 
VESSEL. <DEST1NAT10N_P0RT>. Value  =  "San  Diego"  And 
VESSEL. <CLASS1F1CAT10N>. Value  =  "Unclassified"  Select  Name  = 

VESSEL. <NAME>. Value,  MMSl  =  VESSEL . <MMS1> . Value ,  Est_Arrival  = 

VESSEL. <EST_ARR1VAL>. Value,  Originating_Port  = 

VESSEL. <0R1G1NAT1NG_P0RT>. Value,  Destination_Port  = 

VESSEL . <DEST1NAT10N_P0RT> . Value 

End  Function 
End  Class 

Listing  7.  Language  Integrated  Query  Sample  Code 


The  results  produced  from  this  framework  are  identical  to  those  produced  using 
XPath  as  the  query  language  and  were  already  shown  (Figure  22  and  Figure  23).  Based 
on  the  integration  of  the  query  system  with  the  existing  vessel  data  sets,  we  can  begin  to 
develop  rules  for  our  ID  to  support  the  re-architecting  of  the  system  and  the  specification 
of  our  security  policy  using  RuleML. 
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VI.  THE  INFORMATION  DECLASSIFIER 


In  support  of  the  re-architecting  effort  based  on  the  UML  Use-Case  analysis,  we 
have  added  the  concept  of  an  Information  Declassifier.  The  original  process  flow  of 
Radiant  Alloy  relied  on  queries  to  the  IB  for  direct  results  from  associated  repositories  as 
shown  in  Figure  24. 


The  revised  process  flow  resulting  from  the  rearchitecting  process  now  includes 
the  ID  as  an  element  of  the  architecture  is  shown  in  Figure  25.  The  ID  is  specified  using 
RuleML  and  was  required  to  satisfy  the  security  use-case  that  was  depicted  in  Figure  18 
and  Figure  20. 
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The  high-level  operational  vision  for  the  ID  and  IB  interaction  can  be  explained 
as  follows.  The  IB  is  the  mechanism  for  user  entry  to  the  system  and  executing  queries. 
The  IB  is  also  responsible  for  initiating  the  ID  service  and  passing  both  user  attributes 
and  query  data  to  the  ID.  The  ID,  which  is  replicated  at  all  security  domains  in  the  MLS 
system,  then  begins  its  rule  processing.  The  logical  flow  of  IB  and  ID  interaction  is 
shown  in  Figure  26. 
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Figure  26.  Flow  Chart  of  the  Operational  Vision 


The  parallelograms  represent  input  or  messaging,  the  rectangles  represent 
processing,  the  diamonds  represent  decisions,  and  the  circles  are  on-page  continuations  of 
flow.  This  flow  chart  does  not  show  the  iterative  ID  process  that  must  occur  for  every  IB 
query.  The  ID  is  also  responsible  for  initiating  the  higher  level  ID  services  and  passing 
the  same  parameters  to  the  higher  level  ID  (until  the  top  domain  is  reached).  Beyond  this 
operational  vision  we  must  rely  on  the  individual  rule  set  to  determine  our  policy  and 
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implement  its  functionality.  The  entire  rule  set  to  support  the  Use  Case  of  our  analysis 
comprises  approximately  forty  separate  rules  that  use  forward  chaining,  thereby  allowing 
higher  level  rules  to  link  to  subordinate  rules  or  variables  to  link  fields  in  authorized 
queries  to  the  system,  as  well  as  data  classification  and  user  security  levels  to  form  the 
basis  for  our  evaluative  process. 

Additionally,  we  have  re-routed  queries  from  the  existing  architecture  to  account 
for  the  presence  of  the  ID  and  its  role  in  the  system.  The  Information  Declassifier  must 
act  as  an  enforcer  for  information  flows  that  may  produce  unwanted  leakage.  This 
leakage  could  be  from  disparate  domains,  or  even  within  a  domain  but  between  Roles  and 
to  which  a  particular  subject  is  not  authorized  the  information  that  they  obtain.  These 
rules  that  we  will  describe  and  enact  will  be  generated  in  RuleML.  They  can  be  executed 
on  any  XML  specified  data  or  code  and  are  based  on  our  High-Level  Alert  Use-Case 
scenario.  Three  cases  must  be  addressed  by  the  RuleML  and  Information  Declassifier  for 
the  re-architecting: 

1.  Reroute  all  User- IB  queries  and  Inter-IB  queries-queries  must  be  routed  to 
the  ID  and  passed  to  the  highest  level  ID/IB  to  allow  for  the  inclusion  of 
data  from  alert  messages  that  are  no  longer  visible  at  the  requestor’s 
classification  level.  This  includes  both  intra-domain  and  inter-domain 
interaction. 

2.  Reroute  all  Alert  Notification  Messaging-Alerts  must  be  routed  through 
the  system  (we  cannot  control  out-of-band),  but  we  must  provide  for  a 
distribution  method  within  the  system  through  the  ID. 

3.  Reroute  all  Repository  Responses-Data  responses  must  be  routed  through 
the  IB  /  ID  pair,  to  verify  appropriately  for  action  against  the  rule  engine. 
This  will  help  in  efforts  of  need  to  share  and  need  not  to  share  while 
providing  support  to  allow  for  information  filtering. 

The  Information  Broker  implementation  must  be  extended  to  contain  an 
orchestration  mechanism  to  invoke  the  ID.  Similar  to  the  rules  for  a  security  kernel,  we 
must  ensure  that  the  orchestration  mechanism  in  the  IB  service  is  always  invoked  and 
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tamperproof.  Whenever  a  request  or  query  reaches  the  IB  service,  the  orchestration  will 
invoke  the  ID  and  pass  the  same  informational  query,  along  with  the  user  credentials  and 
role  details  in  the  messaging.  The  IB  will  continue  to  execute  its  primary  objective  in 
gathering  data  from  the  associated  data  repositories,  but  it  will  also  wait  for  a  response 
from  the  ID  service  that  was  invoked.  There  will  be  two  cases  of  response  from  the  ID.  A 
negative  response  from  the  ID  will  result  in  the  IB  returning  whatever  data  it  found 
initially,  with  respect  to  the  role-mapped  permissions  for  the  user.  A  positive  response 
from  the  ID  will  cause  the  IB  to  augment  its  results  with  the  additional  information  that 
the  ID  returned. 

A  means  to  mitigate  risk  is  to  create  and  derive  the  rule  base  that  will  be  used  by 
the  ID.  Depending  upon  the  most  critical  information  sharing  concerns  and  the  need  to 
prevent  specified  misuse,  we  will  create  a  rule  base  that  will  isolate  and  address  those 
areas.  This  will  never  be  all  inclusive,  nor  will  each  of  the  cases  be  mutually  exclusive. 
Certain  information  sharing  rules  will  overtly  conflict  with  others  and  will  have  to  be 
reconciled  to  achieve  an  acceptable  result  for  information  flow.  This  ambiguity  must  be 
reconciled  in  the  development  of  the  overall  security  policy.  This  support  of  the  re¬ 
architecting  effort  based  on  the  UML  Use-Case  will  help  to  ensure  that  we  maintain  our 
security  property  for  the  emergent  behaviors  that  are  most  critical  within  our  information 
system,  based  on  the  expressed  operational  context  used  in  this  research. 

A.  RULES  FOR  THE  INFORMATION  DECLASSIFIER 

RuleML’s  expressive  power  offers  the  potential  to  implement  a  rule  engine  for  an 
ID  that  is  robust  enough  to  function  in  an  MLS  environment,  yet  still  flexible  enough  to 
allow  for  intricate  rule  usage.  The  rules  generated  for  a  RuleML-based  ID  must  be 
reactionary;  much  like  the  rules  for  an  Access  Control  List  (ACL)  on  a  router.  The  base 
set  of  rules  is  reactionary  and,  once  the  requisite  functionality  is  enabled,  can  be 
augmented  with  derivation  and  transformational  rules.  These  rules  can  be  replicated 
between  domains  and  changed  readily,  yet  they  still  have  sufficient  expressive  power  to 
specify  the  AIS  security  policy. 
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Precise  translation  from  an  English  language  security  policy  to  a  specification  for 
that  same  policy  expressed  with  RuleML  is  difficult.  In  support  of  the  re-architecting,  and 
in  order  to  ensure  the  soundness  and  completeness  of  our  ID  implementation  using 
RuleML,  two  main  categories  were  addressed  to  meet  our  security  use  case.  Intra-domain 
rules  were  necessary  to  provide  for  filtering  of  information  within  a  domain,  while  inter¬ 
domain  queries  allow  for  the  injection  of  data  necessary  when  Alert  Messages  are  present 
in  the  system  and  data  must  be  added  to  avoid  the  loss  of  safety.  RuleML  allows  for 
predicates  and  rules  to  be  sourced  either  internally  (within  a  service)  or  externally  (a  call 
to  a  separate  service).  In  the  case  of  our  ID,  we  highlighted  the  Reaction  RuleML  side  to 
produce  a  positive  response  from  our  ruleset.  The  entire  developed  ruleset  consists  of 
forty-one  rules  which  will  be  covered  in  detail.  Some  of  these  rules  were  created  to 
replicate  other  services  and  responses  within  our  envisioned  system  that  were  both 
beyond  the  scope  and  could  not  easily  be  replicated  for  this  research.  The  RuleML  set  can 
be  expressed  in  Backus-Naur  form  (BNF)  and  the  trace  through  the  ruleset  can  be 
completed  as  though  the  entire  ruleset  were  a  context-free  grammar  (CFG). 

The  predicates  used  for  the  creation  of  the  ruleset  are  shown  in  Listing  8.  These 
mappings  indicate  possible  values  utilized  for  the  MDA  scenario  and  the  header  code  is 
included  in  Listing  9. 
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Alert_Present_Response  “True”  |  “False”  (Currently  User  defined  -  would  be  IB 
service  response) 

Classification_Level  “Unclassified”  |  “Secret”  |  “Top  Secret” 
Data_Classification_Level  “Unclassified”  |  “Secref’  |  “Top  Secref’ 

EWO  Valid  Query  User_Role  &&  User_Security_level  &&  PDP  Decision 
HM  Queries  “Originating  Port”  |  “Destination  Port” 

HM  Valid  Query  Oakland  Harbormaster  query  is  valid  destination  |  Oakland 
Harbormaster  query  is  valid  origination  |  SD  Harbormaster  query  is  valid  destination 
I  SD  Harbormaster  query  is  valid  origination 
lB_Classification_Level  “Unclassified”  |  “Secref’  |  “Top  Secref’ 
lB_Response_Wait  Valid_Query  &&  Query  Requires  Data  lnsertion 
PDP  Decision  ->  User_Role_Permissions 
Query_Requires_Data_Insertion  Alert_Present_Response 

Return_IB_Results  “Vessel  Results  from  Unclassified  IB”  |  “Vessel  Results  from 
Unclassified  IB  with  ID  Injection”  |  “Vessel  Results  from  Secret  IB  and  Unclassified 
IB”  I  “Vessel  Results  from  Secret  IB  and  Unclassified  IB  with  ID  Injection”  | 
“Vessel  Results  from  Top  Secret  IB  and  Secret  IB  and  Unclassified  IB” 
Security_Level  ->  “Unclassified”  |  “Secref’  |  “Top  Secref’ 

User  Role  ->  “EWO”  |  “Electronic  Warfare  Officer”  |  “Harbormaster”  |  “Harbormaster 
San  Diego”  |  “Harbormaster  Oakland”  |  “Harbormaster  Shanghai” 

User  Role  Location  “San  Diego”  |  “Oakland”  |  “Shanghai”  |  “Not  Reported” 

User  Role  Permissions  “True”  |  “False”  (Currently  User  defined  -  would  be  PDP 
service  response) 

User_Security_Level  “Unclassified”  |  “Secref’  |  “Top  Secret” 

Valid  Query  HM  Valid  Query  |  EWO_Valid_Query 

Vessel  Classification  Level  User  Role  &&  User_Security_level  &&  PDP  Decision 
Vessel  Destination  Port  User_Role_Location 
Vessel_Originating_Port  User_Role_Location 
Listing  8.  RuleML  Predicate  Listing 

The  rules  created  for  this  scenario  were  numbered  using  RulelDs  from  zero  to  forty 
and  encoded  after  creating  a  natural  language  description  for  the  rule.  Header  data  is 
established  to  begin  the  RuleML  coding.  This  includes  creating  the  rule  base  and 
establishing  the  location  and  naming  for  rules  with  the  uniform  resource  identifier  (URI). 
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<?xml  version="l . 0"  encoding="utf-8"?> 

<RuleML  xmlns="http : //www . ruleml . org/0 . 91/xsd"> 
<Rulebase> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>MDA_Scenario_Arvay_current</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>12/4/2008</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<!--Rule  Policy  Inf ormation_Declassif ier--> 
<!--oid  of  the  rule  base  /  module  --> 

<Ind>In format ion  Declassifier </ Ind> 


Listing  9.  RuleML  Header  Code  for  Information  Declassifier 


The  rules  are  constructed  to  produce  a  confirmed  result,  positive  or  negative,  for 
every  query.  No  implicit  deny  rule  was  established  for  this  proof-of-concept  ruleset.  Each 
of  the  rules  is  detailed  in  Appendix  A  and  contains  summary  information  for  the  intent  of 
the  rule  as  well  as  the  actual  RuleML  code  that  enacts  the  rule  within  the  system. 

The  intended  functionality  of  the  information  declassifier  consists  of  several  parts 
and  rules  were  written  to  fulfill  those  component  functions  as  shown  in  Figure  27  and  the 
summary  of  the  rule  naming  is  shown  in  Listing  10. 


106 


Figure  27.  Functional  Support  for  Ruleset 

RulelD  0:  Alert  Not  Valid  for  Role  Location. 

RulelD  1 :  Alert  Notification  is  Present. 

RulelD  2:  Est  Location  for  Role. 

RulelD  3:  IB  Results  0. 

RulelD  4:  Oakland  Harbormaster  query  is  valid  destination. 
RulelD  5:  PDP  Decision. 

RulelD  6:  Positive  ID  Response  to  IB  for  Alert. 

RulelD  7:  Query  is  Valid. 

RulelD  8:  Alert  Notification  is  Absent. 

RulelD  9:  Alert  SD  Secret  IB. 

RulelD  10:  EWO  Query  is  Valid. 

RulelD  ll  :  IB  Results  2. 

RulelD  12:  Negative  ID  Response  to  IB  for  Alert. 
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RulelD  13:  Oakland  Harbormaster  query  is  valid  destination  2. 
RulelD  14:  PDP  Decision  2 . 

RulelD  15:  Query  is  Invalid. 

RulelD  16:  Alert  SD  Secret  IB  2. 

RulelD  17:  IB  Results  S. 

RulelD  18:  Oakland  Harbormaster  query  is  valid  origination. 
RulelD  19:  Alert  SD  TSIB. 

RulelD  20:  EWO  Query  is  Valid  2. 

RulelD  21:  IB  Results  4. 

RulelD  22:  Oakland  Harbormaster  query  is  valid  origination  2. 
RulelD  23:  Alert  SD  TSIB. 

RulelD  24:  IB  Results  5. 

RulelD  25:  SD  Harbormaster  query  is  valid  destination. 

RulelD  26:  Alert  Oak  Secret  IB . 

RulelD  27:  IB  Results  6. 

RulelD  28:  SD  Harbormaster  query  is  valid  destination  2. 
RulelD  29:  Alert  Oak  Secret  IB  2. 

RulelD  30:  SD  Harbormaster  query  is  valid  origination. 

RulelD  31:  Alert  Oak  TS  IB . 

RulelD  32:  SD  Harbormaster  query  is  valid  origination  2. 
RulelD  33:  Alert  Oak  TSIB  2. 

RulelD  34:  IB  Results  0.1. 

RulelD  35:  IB  Results  0.2. 

RulelD  36:  IB  Results  0.3 . 

RulelD  37:  No  Alert  IB. 

RulelD  38:  IB  Results  2.1. 

RulelD  39:  EWO  Query  is  Invalid. 

RulelD  40:  HM  Query  is  Invalid. 

Listing  10.  RuleML  Rule  Names 
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As  this  proof  of  concept  was  not  applied  to  a  production  system,  many  conditional 
rules  were  required  to  establish  the  user  credentials  and  origination  data  of  system 
queries.  These  are  support  rules  to  allow  the  validation  checks  and  path  determination  for 
the  Information  Declassifier  to  operate.  With  a  live  production  system  the  use  of  a  Global 
Content  Delivery  System  (GCDS),  or  even  Microsoft  Active  Directory  in  a  deprecated 
case  would  suffice  to  provide  this  level  of  background  and  statistical  data.  Additionally, 
the  checks  on  alert  decisioning  were  not  based  on  a  live  repository,  so  the  rules  9,  16,  19, 
23,  26,  29,  31,  and  33  were  all  created  to  replicate  this  functionality  depending  on  the 
variable  set  established  in  the  originating  query  and  sample  case.  With  a  live  repository 
and  a  web  application  tied  into  an  Oracle  (or  other)  database,  these  rules  would  be 
replaced  with  a  real-time  response  from  that  instance.  Each  of  these  rules  combine  to 
form  the  basis  for  expressing  our  information  broker’s  interaction  with  a  declassifier 
using  RuleML,  and  demonstrate  the  interaction  required  with  using  a  rule  engine  to 
exercise  these  rules. 

1.  Intra-Domain  (Filtering) 

By  establishing  rules  that  can  be  enforced  within  a  single  information  domain,  we 
can  effectively  limit  the  ability  of  users  to  obtain  information  to  which  they  are  not 
authorized.  One  aspect  of  this  intra-domain  restriction  can  be  represented  by  our  desire  to 
restrict  a  Harbormaster’s  queries  to  those  ports  which  directly  apply  to  his  Role  location. 
Accordingly,  if  the  San  Diego  Harbormaster  wants  to  query  the  system  for  data,  then  we 
should  only  give  him  the  data  necessary  for  the  execution  of  his  role.  In  practice,  we  want 
the  ID  to  have  a  rule  that  represents  the  idea  that  “the  Harbormaster’s  query  must  only 
obtain  data  which  includes  his  Role’s  port  (i.e.,  San  Diego)  as  either  the  Origination  Port 
or  the  Destination  Port.’’ 

2.  Inter-Domain  (Injection) 

The  ID  must  act  as  an  intermediary  between  varying  security  domains, 
represented  by  an  IB  at  each  domain  level.  This  is  necessary  to  process  queries  from 
lower  classification  levels  and  to  pull  data  pertaining  to  Alert  Message  Notifications  from 
higher  classification  level  data  stores.  When  a  higher  classification  or  different  domain 
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level  user  touehes  the  data  pertaining  to  a  VOI,  the  lower  level  user  ean  no  longer  view 
that  data.  This  may  be  counter  to  their  role  and  responsibilities  where  they  are,  in  fact, 
entitled  and  required  to  access  this  information.  This  information  could  also  be  critical  to 
their  performance  of  duties  while  fulfilling  an  established  Role  in  the  system.  The  ID 
would  first  receive  a  query  message  from  a  domain  level  IB.  This  IB  is  attempting  to 
provide  a  user  with  requested  data,  but  in  order  to  prevent  an  information  flow  problem 
as  described  in  our  Use-Case  scenario,  must  ask  the  higher  level  IB  for  Alert  Message 
information.  This  request  to  a  different  domain  IB,  must  be  processed  through  a  trusted 
entity,  in  this  case  the  Information  Declassifier  that  resides  between  the  respective  IB 
domains.  As  an  IB  receives  a  lower  level  IB  query,  it  must  first  send  a  similar  request  to 
its  higher  level  (thru  the  ID  between  its  domains),  then  it  must  query  its  own  Alert 
Message  Notification  stores  for  data.  Pending  the  results  of  the  higher  level  answer  and 
its  own  Alert  Message  result,  it  will  generate  a  Negative  Response  for  No  Data  Found,  or 
a  Positive  Response  with  the  associated  dataset.  The  Positive  Response  will  be 
aggregated  to  the  lower  level’s  own  query  results,  while  the  Negative  Response  will 
result  in  the  IB  (at  whatever  level)  processing  the  query  and  returning  any  result  it  finds 
(based  on  user  permissions  for  the  Role). 

3.  Individual  Ruleset  Descriptions  and  Purpose 

RulelD  0  is  titled  Alert  Not  Valid  for  Role  Location.  This  rule  is  intended  to 
eliminate  possibilities  for  Alert  Messaging  responses  that  are  not  valid  for  our  scenario.  If 
an  Alert  exists  for  Los  Angeles  in  the  system  (at  a  higher  level  IB),  then  this  rule  toggless 
that  notification  to  FALSE,  since  it  does  not  apply  to  the  port  of  San  Diego. 

RulelD  1  is  titled  Alert  Notification  is  Present.  This  rule  is  intended  to  set  the 
variable  Query _Requires_Data_Insertion  to  TRUE,  if  the  higher  level  IB  possesses  an 
Alert  Message.  In  this  ruleset,  the  external  reference  is  not  made,  but  invoked  through  the 
use  of  an  internally  generated  variable  for  the  sourcing. 

RulelD  2  is  titled  Est  Location  for  Role.  This  rule  is  intended  to  fix  the 
assignment  of  the  user’s  role  location  to  the  results  being  returned  from  the  IB.  This  will 
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allow  for  additional  fdtering  to  match  the  user’s  location  with  vessel  results  from  the  data 
repositories  that  match  with  origination  or  destination  ports. 

RulelD  3  is  titled  IB  Results  0.  This  is  one  of  the  ten  IB  results  rules  that  is 
intended  to  replicate  the  results  from  an  actual  IB.  It  is  used,  based  on  the  variables  it  is 
sourced  with  to  provide  an  expected  result  when  testing  the  rule  base  with  a  sample 
query.  In  this  case,  it  returns  the  IB  result  of  “Vessel  Results  from  Unclassified  IB  with 
ID  Injection  for  Oakland  Alert.’’  This  is  done  after  checking  the  user’s  security  level  and 
for  the  presence  of  an  alert  for  this  location.  This  rule  was  created  to  allow  for 
Harbormaster  queries  from  the  port  of  Oakland  as  an  extension  to  the  San  Diego  port 
accounted  for  in  our  scenario. 

RuIelD  4  is  titled  Oakland  Harbormaster  query  is  valid  destination.  This  is  one  of 
the  rules  used  as  an  extension  to  our  primary  scenario,  which  would  allow  for  the  port  of 
Oakland  queries  to  also  work  in  the  system.  It  is  used  to  verify  the  user  role,  the  role 
location,  the  PDF  decision,  and  the  type  of  query  before  deciding  that  it  is  a  valid  query 
and  should  be  processed  by  the  IB. 

RuIelD  5  is  titled  PDF  Decision.  This  is  an  externally  sourced  rule  that  would  be 
completed  by  the  Policy  Decision  Point  service  in  our  SOA  system.  It  is  used,  based  on  the 
variables  it  is  sourced  with,  to  provide  a  decision  for  that  user’s  access  to  resources  in  the 
system.  In  this  implementation,  it  is  not  referenced  from  an  actual  external  PDF  service. 

RulelD  6  is  titled  Positive  ID  Response  to  IB  for  Alert.  This  rule  is  used  to 
indicate  a  positive  response  to  the  presence  of  an  Alert  Message  at  a  higher  level  IB  and 
verifies  that  the  query  to  the  IB  is  valid  based  on  the  roles  active  in  our  system.  This  rule 
ensures  that  the  IB  response  that  was  previously  returned  directly  to  the  user  is  now 
processed  through  the  ID  and  missing  data  is  injected  to  the  query  if  necessary,  to 
eliminate  the  Misuse  Case  and  as  a  <Prevent>  feature  of  our  Security  Use  Case.  This  rule 
is  designed  to  verify  other  rules  that  determine  if  the  query  to  the  system  is  valid,  and  if 
the  response  from  the  higher  level  IB  requires  the  system  to  inject  data  before  processing 
the  query  response.  It  also  checks  if  the  query  requires  data  insertion,  which  is  sourced 
from  the  higher  level  IBs.  If  both  of  these  conditions  are  TRUE,  then  the  IB  that  received 
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the  query  is  informed  that  its  response  to  the  user  must  wait  for  the  injection  messaging 
from  the  ID  service  prior  to  returning  results  to  the  user. 

RulelD  7  is  titled  Query  is  Valid.  This  is  a  filtering  rule  and  is  used  to  verify  that  the 
user  (EWO  or  Harbormaster)  is  requesting  an  allowable  query.  It  is  sourced  from  two  other 
rules,  which  check  the  validity  of  the  query  against  each  actor’s  allowable  query  set. 

RulelD  8  is  titled  Alert  Notification  is  Absent.  This  rule  is  intended  to  set  the 
variable  Query _Requires_Data_Insertion  to  FALSE,  if  the  higher  level  IB  does  not 
possess  an  Alert  Message.  In  this  ruleset,  the  external  reference  is  not  made,  but  invoked 
through  the  use  of  an  internally  generated  variable  for  the  sourcing. 

RulelD  9  is  titled  Alert  SD  Secret  IB.  This  rule  is  used  to  verify  that  when  an  alert 
is  present  at  the  Secret  level  IB,  intended  for  San  Diego,  and  the  requestor  is  at  the 
Unclassified  security  level,  that  the  Alert_Present_Response  is  set  to  TRUE.  This  will 
indicate  to  the  ID  and  IB  that  an  alert  is  present  that  pertains  to  the  user  query,  and  that 
the  user  is  below  the  alert’s  classification  level. 

RulelD  10  is  titled  EWO  Query  is  Valid.  This  is  a  filtering  rule  and  is  used  to 
verify  that  the  user  fulfilling  the  EWO  role  is  requesting  an  allowable  query.  It  is  checked 
against  the  actor’s  allowable  query  set,  to  determine  validity. 

RulelD  1 1  is  titled  IB  Results  2.  This  is  one  of  the  ten  IB  results  rules  that  is 
intended  to  replicate  the  results  from  an  actual  IB.  It  is  used,  based  on  the  variables  it  is 
sourced  with  to  provide  an  expected  result  when  testing  the  rule  base  with  a  sample 
query.  In  this  case,  it  returns  the  IB  result  of  “Vessel  Results  from  Secret  IB  and 
Unclassified  IB  with  ID  Injection  for  Oakland  Alert.’’  This  is  done  after  checking  the 
user’s  security  level  and  for  the  presence  of  an  alert  for  this  location.  The  IB,  in  this  case, 
would  return  its  regular  result  from  both  the  Unclassified  and  Secret  level  IB  (since  the 
user  is  at  the  Secret  level),  and  then  the  required  Alert  Message  insertion  from  the  TS  IB. 
This  rule  was  created  to  allow  for  Harbormaster  queries  from  the  port  of  Oakland  as  an 
extension  to  the  San  Diego  port  accounted  for  in  our  scenario. 

RulelD  12  is  titled  Negative  ID  Response  to  IB  for  Alert.  This  rule  provides  an 
acknowledgment  of  a  negative  result  for  the  presence  of  an  alert  message.  This  is  used  to 
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trigger  other  rules  in  the  ruleset  and  to  ensure  that  the  ID  returns  a  result  in  all  cases. 
Without  this  rule,  it  is  possible  for  the  ID  to  return  nothing,  which  allows  for  ambiguity  in 
the  ruleset.  The  rule  checks  if  the  query  requires  data  insertion,  which  is  sourced  from  the 
higher  level  IBs.  If  FALSE,  then  the  IB  that  received  the  query  is  informed  that  its 
response  to  the  user  does  not  need  to  wait  for  the  ID  injection  messaging  prior  to 
returning  results  to  the  user. 

RulelD  13  is  titled  Oakland  Harbormaster  query  is  valid  destination  2.  This  rule 
is  almost  a  duplicate  of  RulelD  4,  but  is  used  to  support  an  alternative  method  of 
designating  roles.  In  this  case,  if  the  role  is  listed  as  Harbormaster  Oakland,  instead  of  the 
generic  Harbormaster  designation,  then  the  rule  will  process  similarly.  This  is  one  of  the 
rules  used  as  an  extension  to  our  primary  scenario,  which  would  allow  for  the  port  of 
Oakland  queries  to  also  work  in  the  system.  It  is  used  to  verify  the  user  role,  the  role 
location,  the  PDF  decision,  and  the  type  of  query  before  deciding  that  it  is  a  valid  query 
and  should  be  processed  by  the  IB. 

RulelD  14  is  titled  PDF  Decision  2.  This  is  an  externally  sourced  rule  that  would 
be  completed  by  the  Policy  Decision  Point  service  in  our  SOA  system.  It  is  used,  based 
on  the  variables  it  is  sourced  with,  to  provide  a  decision  for  that  user’s  access  to  resources 
in  the  system.  In  this  implementation,  it  is  not  referenced  from  an  actual  external  PDP 
service,  and  this  rule  is  intended  to  provide  a  positive  response  to  the  service  check  for  a 
negative  response. 

RulelD  15  is  titled  Query  is  Invalid.  This  is  a  filtering  rule  and  is  used  to  verify 
that  the  user  (EWO  or  Harbormaster)  is  requesting  an  allowable  query.  It  is  sourced  from 
two  other  rules,  which  check  the  validity  of  the  query  against  each  actor’s  allowable 
query  set.  This  rule  is  intended  to  provide  a  positive  response  to  the  query  check  in  the 
case  of  a  negative  response. 

RulelD  16  is  titled  Alert  SD  Secret  IB  2.  This  rule  is  used  to  verify  that  when  an 
alert  is  present  at  the  Secret  level  IB,  intended  for  San  Diego,  and  the  requestor  is  at  the 
Unclassified  security  level,  that  the  Alert _Present_Response  is  set  to  TRUE.  This  will 
indicate  to  the  ID  and  IB  that  an  alert  is  present  that  pertains  to  the  user  query,  and  that 
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the  user  is  below  the  alert’s  classification  level.  This  rule  is  equivalent  to  RulelD  9  and  is 
used  to  support  an  alternative  method  of  designating  roles.  In  this  case,  if  the  role  is  listed 
as  the  generic  Harbormaster,  instead  of  the  Harbormaster  San  Diego  designation,  then  the 
rule  will  process  similarly. 

RulelD  17  is  titled  IB  Results  3.  This  is  one  of  the  ten  IB  results  rules  that  is 
intended  to  replicate  the  results  from  an  actual  IB.  It  is  used,  based  on  the  variables  it  is 
sourced  with  to  provide  an  expected  result  when  testing  the  rule  base  with  a  sample 
query.  In  this  case,  it  returns  the  IB  result  of  “Vessel  Results  from  Secret  IB  and 
Unclassified  IB.’’  This  is  done  after  checking  the  user’s  security  level  and  for  the 
presence  of  an  alert  for  this  location.  The  IB,  in  this  case,  will  return  its  regular  result 
from  both  the  Unclassified  and  Secret  level  IB  (since  the  user  is  at  the  Secret  level). 

RulelD  18  is  titled  Oakland  Harbormaster  query  is  valid  origination.  This  rule  is 
supports  an  alternative  method  of  designating  roles.  In  this  case,  if  the  role  is  listed  as 
Harbormaster  Oakland,  instead  of  the  generic  Harbormaster  designation,  then  the  rule 
will  process  similarly.  This  is  one  of  the  rules  used  as  an  extension  to  our  primary 
scenario,  which  would  allow  for  the  port  of  Oakland  queries  to  also  work  in  the  system.  It 
is  used  to  verify  the  user  role,  the  role  location,  the  PDF  decision,  and  that  the  query  type 
is  for  an  Originating  Port  before  deciding  that  it  is  a  valid  query  and  should  be  processed 
by  the  IB. 

RulelD  19  is  titled  Alert  SD  TS  IB.  This  rule  serves  as  a  trigger  within  the  ruleset 
to  identify  that  an  Alert  Message  is  present  and  to  verify  the  level  of  the  Alert  Message 
against  the  security  level  of  the  user  producing  the  query.  This  rule  is  used  to  verify  that 
when  an  alert  is  present  at  the  Top  Secret  level  IB,  intended  for  San  Diego,  the  requestor 
is  at  the  Unclassified  or  Secret  security  level,  and  that  the  Alert _Present_Response  is  set 
to  TRUE.  This  will  indicate  to  the  ID  and  IB  that  an  alert  is  present  that  pertains  to  the 
user  query,  and  that  the  user  is  below  the  alert’s  classification  level. 

RulelD  20  is  titled  EWO  Query  is  Valid  2.  This  is  a  filtering  rule  and  is  used  to 
verify  that  the  user  fulfilling  the  EWO  role  is  requesting  an  allowable  query.  It  is  checked 
for  validity  against  the  actor’s  allowable  query  set.  This  rule  is  equivalent  to  RulelD  10, 
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but  accounts  for  a  different  role  naming  convention.  In  this  case,  the  user’s  role  is 
Electronic  Warfare  Officer,  instead  of  EWO. 

RulelD  21  is  titled  IB  Results  4.  This  is  one  of  the  ten  IB  results  rules  that  is 
intended  to  replicate  the  results  from  an  actual  IB.  It  is  used,  based  on  the  variables  it  is 
sourced  with,  to  provide  an  expected  result  when  testing  the  rule  base  with  a  sample 
query.  In  this  case,  it  returns  the  IB  result  of  “Vessel  Results  from  Unclassified  IB.”  This 
is  done  after  checking  the  user’s  security  level  and  for  the  presence  of  an  alert  for  this 
location  being  FALSE.  The  IB,  in  this  case,  would  return  its  regular  result  from  the 
Unclassified-level  IB. 

RulelD  22  is  titled  Oakland  Harbormaster  query  is  valid  origination  2.  This  rule 
is  almost  a  duplicate  of  RulelD  18,  but  is  used  to  support  an  alternative  method  of 
designating  roles.  In  this  case,  if  the  role  is  listed  as  the  generic  Harbormaster,  instead  of 
the  Harbormaster  Oakland  designation,  then  the  rule  will  process  similarly.  This  is  one  of 
the  rules  used  as  extension  to  our  primary  scenario,  which  would  allow  for  the  port  of 
Oakland  queries  to  also  work  in  the  system.  It  is  used  to  verify  the  user  role,  the  role 
location,  the  PDF  decision,  and  the  type  of  query  is  an  originating  port  query  before 
deciding  whether  it  is  a  valid  query  and  should  be  processed  by  the  IB. 

RulelD  23  is  titled  Alert  SD  TS  IB.  This  rule  is  used  to  verify  that  when  an  alert  is 
present  at  the  Top  Secret  level  IB,  intended  for  San  Diego,  and  the  requestor  is  at  the 
Unclassified  or  Secret  security  level,  that  the  Alert _Present_Response  is  set  to  TRUE. 
This  will  indicate  to  the  ID  and  IB  that  an  alert  is  present  that  pertains  to  the  user  query, 
and  that  the  user  is  below  the  alert’s  classification  level.  This  rule  is  equivalent  to  RulelD 
19  and  is  used  to  support  an  alternative  method  of  designating  roles.  In  this  case,  if  the 
role  is  listed  as  the  generic  Harbormaster,  instead  of  the  Harbormaster  San  Diego 
designation,  then  the  rule  will  process  similarly. 

RulelD  24  is  titled  IB  Results  5.  This  is  one  of  the  ten  IB  results  rules  that  is 
intended  to  replicate  the  results  from  an  actual  IB.  It  is  used,  based  on  the  variables  it  is 
sourced  with  to  provide  an  expected  result  when  testing  the  rule  base  with  a  sample 
query.  In  this  case,  it  returns  the  IB  result  of  “Vessel  Results  from  TS  IB,  Secret  IB  and 
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Unclassified  IB.”  This  is  done  after  ehecking  the  user’s  seeurity  level  is  equal  to  Top 
Secret.  The  user  in  this  ease  is  authorized  all  data  from  eaeh  of  the  elassification  levels 
and  does  not  require  injection  to  the  IB  results. 

RulelD  25  is  titled  SD  Harbormaster  query  is  valid  destination.  This  rule  is  used 
to  verify  the  user  role  as  Harbormaster,  the  role  location  is  San  Diego,  the  PDF  deeision 
is  TRUE,  and  the  query  is  both  valid  and  of  the  type  Destination  Port  Query  before 
deciding  whether  it  is  valid  and  should  be  proeessed  by  the  IB. 

RulelD  26  is  titled  Alert  Oak  Secret  IB.  This  rule  is  established  as  a  trigger  within 
the  ruleset  to  identify  that  an  Alert  Message  is  present  and  to  verify  the  level  of  the  Alert 
Message  against  the  security  level  of  the  user  producing  the  query.  This  particular  rule  is 
used  as  an  extension  to  our  baseline  scenario  to  aeeount  for  users  at  the  port  of  Oakland. 
This  will  indicate  to  the  ID  and  IB  that  an  alert  is  present  that  pertains  to  the  user  query, 
and  that  the  user  is  below  the  alert’s  classifieation  level. 

RulelD  27  is  titled  IB  Results  6.  This  is  one  of  the  ten  IB  results  rules  that  is 
intended  to  replicate  the  results  from  an  actual  IB.  It  is  used,  based  on  the  variables  it  is 
sourced  with  to  provide  an  expeeted  result  when  testing  the  rulebase  with  a  sample  query. 
In  this  case,  it  returns  the  IB  result  of  “Invalid  Query!”  This  is  done  after  cheeking  the 
query  validity  from  the  Valid  Query  variable. 

RulelD  28  is  titled  SD  Harbormaster  query  is  valid  destination  2.  This  rule  is 
identieal  in  functionality  to  RulelD  25,  but  supports  the  extended  role  eonvention  using 
Harbormaster  San  Diego  instead  of  the  generic  Harbormaster  role.  This  rule  is  used  to 
verify  the  user  role  as  Harbormaster  San  Diego,  the  PDF  deeision  is  TRUE,  and  the  type 
of  query  is  Destination  Port  Query  before  deeiding  that  it  is  valid  and  should  be 
proeessed  by  the  IB. 

RulelD  29  is  titled  Alert  Oak  Secret  IB  2.  This  rule  is  established  as  a  trigger 
within  the  ruleset  to  identify  that  an  Alert  Message  is  present  and  to  verify  the  level  of  the 
Alert  Message  against  the  security  level  of  the  user  produeing  the  query.  It  is  identical  in 
functionality  to  RulelD  26,  but  supports  the  generic  role  moniker  of  Harbormaster 
instead  of  Harbormaster  Oakland.  This  particular  rule  is  used  as  an  extension  to  our 
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baseline  scenario  to  account  for  users  at  the  port  of  Oakland.  This  will  indicate  to  the  ID 
and  IB  that  an  alert  is  present  that  pertains  to  the  user  query,  and  that  the  user  is  below  the 
alert’s  classification  level. 

RulelD  30  is  titled  SD  Harbormaster  query  is  valid  origination.  This  rule  is 
identical  in  functionality  to  RulelD  32,  but  supports  the  extended  role  convention  using 
Harbormaster  San  Diego  instead  of  the  generic  Harbormaster  role.  This  rule  is  used  to 
verify  the  user  role  as  Harbormaster  San  Diego,  the  PDF  decision  is  TRUE,  and  the  type 
of  query  is  Originating_Port_Query  before  deciding  that  it  is  valid  and  should  be 
processed  by  the  IB.  This  rule  checks  the  query  that  is  being  processed  and  sets 
conditions  to  restrict  the  IB  response  as  a  result.  This  rule  is  designed  to  eliminate  the 
user’s  ability  to  repeatedly  query  the  system  to  troll  for  information,  or  the  lack  of 
information,  again  a  key  element  in  preventing  the  Misuse  Case.  In  the  original  system, 
queries  were  directly  processed  by  the  IB  after  entry.  In  the  re-architected  system,  we 
reroute  all  queries  through  the  ID  (per  Figure  26)  where  we  begin  the  new  data  flow  at 
continuation  point  I  instead  of  direct  processing  by  the  IB  in  the  original  flow.  In  this 
case,  the  query  and  resultant  data  must  include  the  Harbormaster’s  port  (either 
Origination  or  Destination)  for  details  to  be  returned  by  the  IB  and  ID.  This  is  part  of  the 
<Detect>  in  the  Security  Use  Case  that  we  had  to  reroute  queries  in  the  system.  This  will 
prevent  a  Harbormaster  from  continually  querying  the  system  to  get  information  about 
vessels  from  the  system  that  do  not  directly  pertain  to  his  or  her  role  (at  his  location)  and 
his  normal  performance  of  duty.  This  rule  verifies  that  the  user  is  a  Harbormaster  from 
San  Diego  and  conducting  an  Originating  Port  Query,  which  he  is  authorized  because  of 
his  role’s  duties  and  obligations,  as  well  as  a  PDF  service  check  to  validate  the  role’s 
permissions  to  execute  a  basic  query  and  to  access  information  from  the  IB.  The  rule  then 
establishes  this  as  a  valid  query  for  the  San  Diego  Harbormaster,  while  it  also  restricts  the 
query  response  by  limiting  Vessel_Classification_Level  to  the  User_Security_Level,  and 
setting  the  field  for  Vessel_Originating_Port  to  the  User_Role_Location,  or  in  this  case 
San  Diego. 

RulelD  3 1  is  titled  Alert  Oak  TS  IB.  This  rule  is  established  as  a  trigger  within  the 
ruleset  to  identify  that  an  Alert  Message  is  present  and  to  verify  the  level  of  the  Alert 
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Message  against  the  security  level  of  the  user  producing  the  query.  It  is  identical  in 
functionality  to  RulelD  33,  but  supports  the  generic  role  moniker  of  Harbormaster 
instead  of  Harbormaster  Oakland.  This  particular  rule  is  used  as  an  extension  to  our 
baseline  scenario  to  account  for  users  at  the  port  of  Oakland.  This  will  indicate  to  the  ID 
and  IB  that  an  alert  is  present  that  pertains  to  the  user  query,  and  that  the  user  is  below  the 
alert’s  classification  level. 

RulelD  32  is  titled  SD  Harbormaster  query  is  valid  origination  2.  This  rule  is 
almost  a  duplicate  of  RulelD  30,  but  is  used  to  support  an  alternative  method  of 
designating  roles.  In  this  case,  if  the  role  is  listed  as  the  generic  Harbormaster,  instead  of 
the  Harbormaster  San  Diego  designation,  then  the  rule  will  process  similarly.  This  rule 
checks  the  query  that  is  being  processed  and  sets  conditions  to  restrict  the  IB  response  as 
a  result.  This  rule  is  designed  to  eliminate  the  user’s  ability  to  repeatedly  query  the 
system  to  troll  for  information,  or  the  lack  of  information,  serving  as  a  key  element  in 
preventing  the  Misuse  Case.  In  the  original  system,  queries  were  directly  processed  by 
the  IB  after  entry.  In  the  re-architected  system,  we  reroute  all  queries  through  the  ID  (per 
Figure  26)  where  we  begin  the  new  data  flow  at  continuation  point  I  instead  of  direct 
processing  by  the  IB  in  the  original  flow.  In  this  case,  the  query  and  resultant  data  must 
include  the  Harbormaster’s  port  (either  Origination  or  Destination)  for  details  to  be 
returned  by  the  IB  and  ID.  This  is  part  of  the  <Detect>  in  the  Security  Use  Case  that  we 
had  to  reroute  queries  in  the  system.  This  will  prevent  a  Harbormaster  from  continually 
querying  the  system  to  get  information  about  vessels  from  the  system  that  do  not  directly 
pertain  to  his  or  her  role  (at  this  location)  and  their  normal  performance  of  duty.  This  rule 
verifies  that  the  user  is  a  Harbormaster  from  San  Diego  and  conducting  an  Originating 
Port  Query,  which  he  is  authorized  because  of  his  role’s  duties  and  obligations,  as  well  as 
a  PDP  service  check  to  validate  the  role’s  permissions  to  execute  a  basic  query  and  to 
access  information  from  the  IB.  The  rule  then  establishes  this  as  a  valid  query  for  the  San 
Diego  Harbormaster,  while  it  also  restricts  the  query  response  by  limiting 
Vessel_Classification_Level  to  the  User_Security_Level,  and  setting  the  field  for 
Vessel_Originating_Port  to  the  User_Role_Location,  or  in  this  case  San  Diego. 
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RulelD  33  is  titled  Alert  Oak  TS  IB  2.  This  rule  is  established  as  a  trigger  within 
the  ruleset  to  identify  that  an  Alert  Message  is  present  and  to  verify  the  level  of  the  Alert 
Message  against  the  security  level  of  the  user  producing  the  query.  This  rule  is  identical 
in  functionality  to  RulelD  30.  This  particular  rule  is  used  as  an  extension  to  our  baseline 
scenario  to  account  for  users  at  the  port  of  Oakland.  This  will  indicate  to  the  ID  and  IB 
that  an  alert  is  present  that  pertains  to  the  user  query,  and  that  the  user  is  below  the  alert’s 
classification  level. 

RulelD  34  is  titled  IB  Results  0.1.  This  is  one  of  the  ten  IB  results  rules  that  is 
intended  to  replicate  the  results  from  an  actual  IB.  It  is  used,  based  on  the  variables  it  is 
sourced  with  to  provide  an  expected  result  when  testing  the  rule  base  with  a  sample 
query.  In  this  case,  it  returns  the  IB  result  of  “Vessel  Results  from  Unclassified  IB  with 
ID  Injection  for  Oakland  Alert.”  This  is  done  after  checking  the  user’s  security  level  and 
for  the  presence  of  an  alert  for  this  location.  The  IB,  in  this  case,  would  return  its  regular 
result  from  the  Unclassified  level  IB  (since  the  user  is  at  the  Unclassified  level),  and  then 
the  required  Alert  Message  insertion  from  the  higher  (TS  or  Secret)  IB.  The  level  of  the 
Alert  Message  is  not  revealed  to  the  user  from  the  IB.  This  rule  was  created  to  allow  for 
Harbormaster  queries  from  the  port  of  Oakland  as  an  extension  to  the  San  Diego  port 
accounted  for  in  our  scenario. 

RulelD  35  is  titled  IB  Results  0.2.  This  is  one  of  the  ten  IB  results  rules  that  is 
intended  to  replicate  the  results  from  an  actual  IB.  It  is  used,  based  on  the  variables  it  is 
sourced  with,  to  provide  an  expected  result  when  testing  the  rule  base  with  a  sample 
query.  In  this  case,  it  returns  the  IB  result  of  “Vessel  Results  from  Unclassified  IB  with 
ID  Injection  for  San  Diego  Alert.”  This  is  done  after  checking  the  user’s  security  level 
and  for  the  presence  of  an  alert  for  this  location.  The  IB,  in  this  case,  would  return  its 
regular  result  from  the  Unclassified  level  IB  (since  the  user  is  at  the  Unclassified  level), 
and  then  the  required  Alert  Message  insertion  from  the  higher  (TS  or  Secret)  IB.  The 
level  of  the  Alert  Message  is  not  revealed  to  the  user  from  the  IB. 

RulelD  36  is  titled  IB  Results  0.3.  This  is  one  of  the  ten  IB  results  rules  that  is 

intended  to  replicate  the  results  from  an  actual  IB.  It  is  used,  based  on  the  variables  it  is 

sourced  with,  to  provide  an  expected  result  when  testing  the  rule  base  with  a  sample 
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query.  In  this  case,  it  returns  the  IB  result  of  “Vessel  Results  from  Unclassified  IB  with 
ID  Injection  for  San  Diego  Alert.”  This  is  done  after  checking  the  user’s  security  level 
and  for  the  presence  of  an  alert  for  this  location.  The  IB,  in  this  case,  would  return  its 
regular  result  from  the  Unclassified  level  IB  (since  the  user  is  at  the  Unclassified  level), 
and  then  the  required  Alert  Message  insertion  from  the  TS  IB.  The  level  of  the  Alert 
Message  is  not  revealed  to  the  user  from  the  IB. 

RulelD  37  is  titled  No  Alert  IB.  This  rule  serves  as  a  trigger  within  the  ruleset  to 
identify  that  an  Alert  Message  is  not  present  at  a  higher  level  IB.  This  indicates  a 
negative  search  result  from  within  the  IB  (i.e.,  no  alert  message  found). 

RulelD  38  is  titled  IB  Results  2.1.  This  is  one  of  the  ten  IB  results  rules  that  is 
intended  to  replicate  the  results  from  an  actual  IB.  It  is  used,  based  on  the  variables  it  is 
sourced  with,  to  provide  an  expected  result  when  testing  the  rule  base  with  a  sample 
query.  In  this  case,  it  returns  the  IB  result  of  “Vessel  Results  from  Secret  IB  and 
Unclassified  IB  with  ID  Injection  for  San  Diego  Alert.”  This  is  done  after  checking  the 
user’s  security  level  and  for  the  presence  of  an  alert  for  this  location.  The  IB,  in  this  case, 
would  return  its  regular  result  from  both  the  Unclassified  and  Secret  level  IB  (since  the 
user  is  at  the  Secret  level),  and  then  the  required  Alert  Message  insertion  from  the  TS  IB. 

RulelD  39  is  titled  EWO  Query  is  Invalid.  This  is  a  filtering  rule  and  is  used  to 
verify  that  the  user  (EWO)  is  requesting  an  allowable  query.  It  verifies  the  role  of  the 
query  requestor  and  is  intended  to  provide  a  positive  response  to  the  query  check  in  the 
case  of  a  negative  response  (i.e.,  an  invalid  query  request). 

RulelD  40  is  titled  HM  Query  is  Invalid.  This  is  a  filtering  rule  and  is  used  to 
verify  that  the  user  (Harbormaster)  is  requesting  an  allowable  query.  In  this  case,  it 
allows  for  Harbormaster  queries  to  originate  from  San  Diego  and  Oakland  only.  Any 
other  location  for  the  role  of  a  Harbormaster  will  make  the  query  invalid.  It  verifies  the 
role  of  the  query  requestor  and  is  intended  to  provide  a  positive  response  to  the  query 
check  in  the  case  of  a  negative  response  (i.e.,  an  invalid  query  request). 


120 


B.  REGRESSION  TESTING 


Several  rule  engines  exist  for  integration  and  use  with  RuleML.  For  this  research 
we  initially  selected  VDR-Device  [68]  as  a  visual  integrated  development  environment 
and  additionally,  we  used  Acumen  Business’s  The  Rule  Manager  [69]  to  assist  with 
visual  rule  mapping  and  stepping  through  the  proof  cases  for  our  ruleset  with  its  ability  to 
allow  interaction  and  establish  parameter  values  as  the  rule  trace  progresses.  As  a  part  of 
regression  testing  as  each  new  rule  was  implemented  or  changed  a  full  testing  process  of 
all  rules  was  conducted  again.  Three  main  cases  exist  for  our  ruleset  to  provide  a  clear 
and  convincing  argument  that  it  is  sound  and  complete.  The  first  case  is  to  demonstrate 
that  all  intended  functionality  and  usage  that  was  provided  for  in  the  original  system  is 
still  available.  This  is  despite  the  fact  that  we  are  now  going  through  an  additional  service 
and  utilizing  a  RuleML  ruleset  to  specify  our  security  policy.  The  second  case  is  to 
demonstrate  that  the  unintended  use  (and  the  loss  of  safety)  of  the  system  that  was 
described  from  the  misuse  case  is  now  prevented.  The  third  and  final  piece  is  to  show  that 
unintended  or  ancillary  queries  are  not  answered  by  our  system  inadvertently.  This  shows 
that  no  additional  use  is  allowed  by  the  implementation  of  our  ruleset  than  that  which  was 
present  in  the  original  system. 


1.  Intended  Use  Is  Maintained 


The  original  functionality  is  maintained  by  the  system,  despite  the  incorporation 
of  our  re-architecting  and  the  implementation  of  the  ID  and  its  ruleset.  To  show  that  this 


still  works  as  it  did  prior  to  this,  we  will  process  a  query  using  the  following  parameters: 


Type  of  query: 

Role  /  Actor: 

Location: 

Security  Level: 

Alert  Present: 

Alert  Classification  Level: 
Expected  Result: 


Destination  Port 
Harbormaster 
San  Diego 
Unclassified 
False 

Not  Applicable 

“Vessel  Results  from  Unclassified  IB’’ 
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The  expected  result  from  this  query  and  the  RuleML  execution  is  an  IB  response 
of  “Vessel  Results  from  Unclassified  IB”  to  the  user.  The  trace  of  this  query  execution 
through  the  ruleset  can  be  seen  in  Appendix  B,  which  depicts  the  query  and  ruleset  using 
RuleManager’s  Interactive  Rule  Map  functionality.  In  Appendix  B,  the  detailed  view  of 
the  trace  also  shows  the  individual  variables  and  terms  from  within  each  rule  being 
sourced  as  the  engine  completes  its  evaluation.  These  terms  are  referenced  by  the 
individual  rule  and  then  evaluated  to  determine  the  end  result  for  each  rule.  For  this 
query,  Retum_IB_Results  is  the  main  variable  (and  expressed  at  the  root  of  the  rule  tree) 
that  is  sourced  from  the  ten  different  IB  Result  rules.  Those  rules  were  designed  to 
replicate  the  external  services  that  were  not  implemented  for  this  research.  Each  IB 
Result  rule  can  begin  the  trace  to  evaluate  down  to  the  base  predicates  (terminals  in  a 
CFG)  that  are  necessary  to  resolve  or  decide  the  rule.  This  may  be  iterative  in  stepping 
through  other  rules  to  source  the  necessary  values  for  the  rule  in  question.  In  the  first 
query  instance,  the  IB  Results  2.1  rule  (RulelD  38)  is  the  rule  chosen  to  begin  the 
sourcing  of  Retum  IB  Results.  The  trace  is  as  follows: 


1. 

RulelD  38-IB  Results  2.1 

Sourced 

2. 

RulelD  40-HM  Query  is  Invalid 

Fired 

3. 

RulelD  32-SD  Harbormaster  query  is  valid  origination  2 

Did  Not  Fire 

4. 

RulelD  30-SD  Harbormaster  query  is  valid  origination 

Did  Not  Fire 

5. 

RulelD  14-Policy  Decision  Point  2 

Did  Not  Fire 

6. 

RulelD  5-Policy  Decision  Point 

Fired 

7. 

RulelD  28-SD  Harbormaster  query  is  valid  destination  2 

Fired 

8. 

RulelD  25-SD  Harbormaster  query  is  valid  destination 

Did  Not  Fire 

9. 

RulelD  22-Oakland  Harbormaster  query  is  valid  origination  2 

Did  Not  Fire 

10. 

RulelD  18-Oakland  Harbormaster  query  is  valid  origination 

Did  Not  Fire 

11. 

RulelD  13-Oakland  Harbormaster  query  is  valid  destination  2 

Did  Not  Fire 
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Did  Not  Fire 


12.  RulelD  4-Oakland  Harbormaster  query  is  valid  destination 

13.  RulelD  39-EWO  query  is  invalid 

14.  RulelD  20-EWO  query  is  valid  2 

15.  RulelD  lO-EWO  query  is  valid 

16.  RulelD  15-Query  Invalid 

17.  RulelD  7-Query  is  Valid 

18.  RulelD  37-No  Alert  IB 

19.  RulelD  33-Alert  Oak  TS  IB  2 

20.  RulelD  31-Alert  Oak  TS  IB 

21.  RulelD  29- Alert  Oak  Secret  IB  2 

22.  RulelD  26-Alert  Oak  Secret  IB 

23.  RulelD  23-Alert  SD  TS  IB  2 

24.  RulelD  19-Alert  SD  TS  IB 

25.  RulelD  16-Alert  SD  Secret  IB  2 

26.  RulelD  9-Alert  SD  Secret  IB 

27.  RulelD  0-Alert  Not  Valid  for  Role  Location 

28.  RulelD  8-Alert  Notification  is  Absent 

29.  RulelD  1-Alert  Notification  is  Present 

30.  RulelD  12-Negative  ID  Response  to  IB  for  Alert 

3 1 .  RulelD  6-Positive  ID  Response  to  IB  for  Alert 

32.  RulelD  38-IB  Results  2.1 

33.  RulelD  36-IB  Results  0.3 

34.  RulelD  35-IB  Results  0.2 

35.  RulelD  34-IB  Results  0.1 


Fired 

Did  Not  Fire 
Did  Not  Fire 
Fired 
Fired 
Fired 

Did  Not  Fire 
Did  Not  Fire 
Did  Not  Fire 
Did  Not  Fire 
Did  Not  Fire 
Did  Not  Fire 
Did  Not  Fire 
Did  Not  Fire 
Fired 
Fired 

Did  Not  Fire 
Fired 

Did  Not  Fire 
Did  Not  Fire 
Did  Not  Fire 
Did  Not  Fire 
Did  Not  Fire 
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36.  RulelD  27-IB  Results  6 

Did  Not  Fire 

37.  RulelD  24-IB  Results  5 

Did  Not  Fire 

38.  RulelD  21 -IB  Results  4 

Fired 

39.  RulelD  17-IB  Results  3 

Did  Not  Fire 

40.  RulelD  11-IB  Results  2 

Did  Not  Fire 

41.  RulelD  3-IB  Results  0 

Did  Not  Fire 

RulelDs  0-40  were  each  evaluated  and  either  fired  or  did  not  fire.  The  originating  rule 
(Step  1.  IB  Results  2.1)  to  begin  the  sourcing  Did  Not  Fire  in  Step  32.  Despite  the  ruleset 
finding  its  result  after  Step  38  when  RulelD  21  Fired,  the  remaining  rules  are  still 
evaluated  in  the  ruleset  for  completeness.  The  RulelD  21  for  IB  Results  4  produced  the 
expected  result  for  this  query  of  “Vessel  Results  from  Unclassified  IB.”  This  query 
effectively  shows  that  the  ruleset  does  not  hinder  the  intended  functionality  or  usage  of 
the  system.  All  original  queries  that  were  allowed  are  still  supported  with  no  change  to 
the  resultant  data. 

2.  Unintended  Use  Is  Prevented 

The  second  case  for  our  clear  and  convincing  argument  consists  of  our  safety 

property  violation  for  information  flow.  The  misuse  of  the  system  must  be  prevented  by 

our  re-architecting  and  the  implementation  of  the  ID  and  its  ruleset.  To  show  that  this 

misuse  has  been  prevented  we  will  process  a  query  using  the  following  parameters: 

Type  of  query:  Destination  Port 

Role  /  Actor:  Harbormaster 

Location:  San  Diego 

Security  Level:  Unclassified 

Alert  Present:  True 

Alert  Classification  Level:  Secret 

Expected  Result:  “Vessel  Results  from  Unclassified  IB  with  ID 

Injection  for  Port  of  San  Diego” 


The  expected  result  from  this  query  and  the  RuleML  execution  is  an  IB  response 
of  “Vessel  Results  from  Unclassified  IB  with  ID  Injection  for  Port  of  San  Diego”  to  the 

user.  The  trace  of  this  query  execution  through  the  ruleset  can  be  seen  in  Appendix  C, 
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which  depicts  the  query  and  ruleset  using  RuleManager’s  Interactive  Rule  Map 
functionality.  In  Appendix  C,  the  detailed  view  of  the  trace  also  shows  the  individual 
variables  and  terms  from  within  each  rule  being  sourced  as  the  engine  completes  its 
evaluation.  These  terms  are  referenced  by  the  individual  rule  and  then  evaluated  to 
determine  the  end  result  for  each  rule.  For  this  query,  Retum_IB_Results  is  the  main 
variable  (and  expressed  at  the  root  of  the  rule  tree)  that  is  sourced  from  the  ten  different 
IB  Result  rules.  Those  rules  were  designed  to  replicate  the  external  services  that  were  not 
implemented  for  this  research.  Each  IB  Result  rule  can  begin  the  trace  to  evaluate  down 
to  the  base  predicates  (terminals  in  a  CFG)  that  are  necessary  to  resolve  or  decide  the 
rule.  This  may  be  iterative  in  stepping  through  other  rules  to  source  the  necessary  values 
for  the  rule  in  question.  In  the  first  query  instance,  the  IB  Results  2.1  rule  (RulelD  38)  is 
the  rule  chosen  to  begin  the  sourcing  of  Retum_IB_Results.  The  trace  is  as  follows: 


1.  RulelD  38-IB  Results  2.1 

2.  RulelD  40-HM  Query  is  Invalid 

3.  RulelD  32-SD  Harbormaster  query  is  valid  origination  2 

4.  RulelD  30-SD  Harbormaster  query  is  valid  origination 

5.  RulelD  14-Policy  Decision  Point  2 

6.  RulelD  5-Policy  Decision  Point 

7.  RulelD  28-SD  Harbormaster  query  is  valid  destination  2 

8.  RulelD  25-SD  Harbormaster  query  is  valid  destination 

9.  RulelD  22-Oakland  Harbormaster  query  is  valid  origination  2 

10.  RulelD  18-Oakland  Harbormaster  query  is  valid  origination 

11.  RulelD  13-Oakland  Harbormaster  query  is  valid  destination  2 

12.  RulelD  4-Oakland  Harbormaster  query  is  valid  destination 

13.  RulelD  39-EWO  query  is  invalid 


Sourced 

Fired 

Did  Not  Fire 
Did  Not  Fire 
Did  Not  Fire 
Fired 
Fired 

Did  Not  Fire 
Did  Not  Fire 
Did  Not  Fire 
Did  Not  Fire 
Did  Not  Fire 
Fired 
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Did  Not  Fire 


14.  RulelD  20-EWO  query  is  valid  2 

15.  RulelD  lO-EWO  query  is  valid 

16.  RulelD  15-Query  Invalid 

17.  RulelD  7-Query  is  Valid 

18.  RulelD  37-No  Alert  IB 

19.  RulelD  33-Alert  Oak  TS  IB  2 

20.  RulelD  31-Alert  Oak  TS  IB 

21.  RulelD  29- Alert  Oak  Secret  IB  2 

22.  RulelD  26-Alert  Oak  Secret  IB 

23.  RulelD  23-Alert  SD  TS  IB  2 

24.  RulelD  19-Alert  SD  TS  IB 

25.  RulelD  16- Alert  SD  Secret  IB  2 

26.  RulelD  9-Alert  SD  Secret  IB 

27.  RulelD  0-Alert  Not  Valid  for  Role  Location 

28.  RulelD  8-Alert  Notification  is  Absent 

29.  RulelD  1-Alert  Notification  is  Present 

30.  RulelD  12-Negative  ID  Response  to  IB  for  Alert 

3 1 .  RulelD  6-Positive  ID  Response  to  IB  for  Alert 

32.  RulelD  38-IB  Results  2.1 

33.  RulelD  36-IB  Results  0.3 

34.  RulelD  35-IB  Results  0.2 

35.  RulelD  34-IB  Results  0.1 

36.  RulelD  27-IB  Results  6 

37.  RulelD  24-IB  Results  5 


Did  Not  Fire 

Fired 

Fired 

Did  Not  Fire 
Did  Not  Fire 
Did  Not  Fire 
Did  Not  Fire 
Did  Not  Fire 
Did  Not  Fire 
Did  Not  Fire 
Did  Not  Fire 
Fired 

Did  Not  Fire 
Did  Not  Fire 
Fired 

Did  Not  Fire 
Fired 

Did  Not  Fire 
Did  Not  Fire 
Fired 

Did  Not  Fire 
Did  Not  Fire 
Did  Not  Fire 
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38.  RulelD  21-IB  Results  4 


Did  Not  Fire 


39.  RulelD  17-lB  Results  3  Did  Not  Fire 

40.  RulelD  1 1-IB  Results  2  Did  Not  Fire 

41.  RulelD  3-IB  Results  0  Did  Not  Fire 

RulelDs  0^0  were  each  evaluated  and  either  fired  or  not  fired.  The  originating  rule  (Step 
1.  IB  Results  2.1)  to  begin  the  sourcing  Did  Not  Fire  in  Step  32.  Despite  the  ruleset 
finding  its  result  after  Step  34  when  RulelD  35  Fired,  the  remaining  rules  are  still 
evaluated  in  the  ruleset  for  completeness.  The  RulelD  35  for  IB  Results  0.2  produced  the 
expected  result  for  this  query  of  “Vessel  Results  from  Unclassified  IB  with  ID  Injection 
for  Port  of  San  Diego.”  This  query  effectively  shows  that  the  ruleset  does  intervene  and 
provide  for  injection  of  data  to  prevent  the  misuse  case.  This  eliminates  the  ability  of  the 
Harbormaster  to  infer  information  from  the  system  and  regains  the  safety  of  our 
information  flows. 

3.  Additional  Use  Is  Excluded 

The  original  functionality  is  maintained  by  the  system,  despite  the  incorporation 

of  our  re-architecting  and  the  implementation  of  the  ID  and  its  ruleset.  To  show  that  this 

still  works  as  it  did  prior  to  this,  we  will  process  a  query  using  the  following  parameters: 

Type  of  query:  Destination  Port 

Role  /  Actor:  Harbormaster 

Location:  San  Diego 

Security  Level:  Unclassified 

Alert  Present:  False 

Alert  Classification  Level:  Not  Applicable 
Expected  Result:  “Invalid  Query!” 


The  expected  result  from  this  query  and  the  RuleML  execution  is  an  IB  response 
of  “Invalid  Query!”  to  the  user.  The  trace  of  this  query  execution  through  the  ruleset  can 
be  seen  in  Appendix  D,  which  depicts  the  query  and  ruleset  using  RuleManager’s 
Interactive  Rule  Map  functionality.  In  Appendix  D,  the  detailed  view  of  the  trace  also 
shows  the  individual  variables  and  terms  from  within  each  rule  being  sourced  as  the 
engine  completes  its  evaluation.  These  terms  are  referenced  by  the  individual  rule  and 
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then  evaluated  to  determine  the  end  result  for  each  rule.  For  this  query, 
Retum_IB_Results  is  the  main  variable  (and  expressed  at  the  root  of  the  rule  tree)  that  is 
sourced  from  the  ten  different  IB  Result  rules.  Those  rules  were  designed  to  replicate  the 
external  services  that  were  not  implemented  for  this  research.  Each  IB  Result  rule  can 
begin  the  trace  to  evaluate  down  to  the  base  predicates  (terminals  in  a  CFG)  that  are 
necessary  to  resolve  or  decide  the  rule.  This  may  be  iterative  in  stepping  through  other 
rules  to  source  the  necessary  values  for  the  rule  in  question.  In  the  first  query  instance, 
the  IB  Results  2.1  rule  (RulelD  38)  is  the  rule  chosen  to  begin  the  sourcing  of 
Return  IB  Results.  The  trace  is  as  follows: 


RulelD  38-IB  Results  2.1 

Sourced 

RulelD  40-HM  Query  is  Invalid 

Fired 

RulelD  32-SD  Harbormaster  query  is  valid  origination  2 

Did  Not  Fire 

RulelD  30-SD  Harbormaster  query  is  valid  origination 

Did  Not  Fire 

RulelD  28-SD  Harbormaster  query  is  valid  destination  2 

Did  Not  Fire 

RulelD  25-SD  Harbormaster  query  is  valid  destination 

Did  Not  Fire 

RulelD  22-Oakland  Harbormaster  query  is  valid  origination  2 

Did  Not  Fire 

RulelD  18-Oakland  Harbormaster  query  is  valid  origination 

Did  Not  Fire 

RulelD  13-Oakland  Harbormaster  query  is  valid  destination  2 

Did  Not  Fire 

RulelD  4-Oakland  Harbormaster  query  is  valid  destination 

Did  Not  Fire 

RulelD  39-EWO  query  is  invalid 

Fired 

RulelD  20-EWO  query  is  valid  2 

Did  Not  Fire 

RulelD  lO-EWO  query  is  valid 

Did  Not  Fire 

RulelD  15-Query  Invalid 

Fired 

RulelD  7-Query  is  Valid 

Did  Not  Fire 

RulelD  38-IB  Results  2.1 

Did  Not  Fire 

RulelD  36-IB  Results  0.3 

Did  Not  Fire 
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18.  RulelD  35-IB  Results  0.2 

Did  Not  Fire 

19.  RulelD  34-IB  Results  0.1 

Did  Not  Fire 

20.  RulelD  27-IB  Results  6 

Fired 

21.  RulelD  24-IB  Results  5 

Did  Not  Fire 

22.  RulelD  21-IB  Results  4 

Did  Not  Fire 

23.  RulelD  17-IB  Results  3 

Did  Not  Fire 

24.  RulelD  1 1-IB  Results  2 

Did  Not  Fire 

25.  RulelD  3-IB  Results  0 

Did  Not  Fire 

RulelDs  0^0  were  not  all  evaluated  for  this  query.  The  resultant  value  for  the  IB  did  not 
require  information  or  variables  from  part  of  the  ruleset  in  this  query.  Because  we  did  not 
allow  for  actors  outside  of  the  scope  of  our  scenario,  the  query  processed  was  filtered  by 
the  ID  and  deemed  Invalid.  The  originating  rule  (Step  1.  IB  Results  2.1)  to  begin  the 
sourcing  Did  Not  Fire  in  Step  16.  Despite  the  ruleset  finding  its  result  after  Step  20  when 
RulelD  27  Fired,  the  remaining  rules  for  IB  Results  are  still  evaluated  in  the  ruleset  for 
completeness  because  they  contain  the  same  sourcing  predicates  that  are  used  by  the 
other  IB  Result  rules  and  map  to  the  final  Return _IB_Results  variable.  The  RulelD  27  for 
IB  Results  6  produced  the  expected  result  for  this  query  of  “Invalid  Query!”  This  query 
and  the  trace  of  our  RuleML  ID  ruleset  provide  a  clear  and  convincing  argument  that  the 
ruleset  does  not  support  unintended  usage  or  additional  functionality  that  would  not  be 
supported  by  the  original  implementation. 

C.  SUMMARY 

In  order  to  support  the  goal  of  information  sharing,  we  must  not  only  consider 
information  releasability,  but  non-disclosure  of  other  information.  The  flexibility  that  is 
offered  through  the  Information  Declassifier  and  its  execution  of  our  rule  base  for  all 
Information  Broker  interactions  provides  a  positive  step  toward  our  ultimate  goal  of 
secure  information  sharing.  We  have  clearly  shown  through  these  three  test  cases  the 
viability  of  using  RuleML  as  a  CDS  information  flow  control  specification  language  and 
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particularly  within  a  SOA-based  environment.  The  flexibility  of  RuleML  to  account  for 
the  de-classification  problem,  resultant  from  the  BLP  tranquility  principle,  is  limited  only 
by  the  developmental  ability  of  the  human  drivers  creating  the  underlying  policy  in 
RuleML. 


130 


VII.  CONCLUSION 


A.  CONTRIBUTIONS 

In  this  research,  we  have  demonstrated  that  by  introducing  the  contributions  listed 
below  the  safety  properties  of  a  mixed  model  access  control,  SOA-based,  MLS  system 
can  be  preserved,  despite  emergent  challenges  resultant  from  the  composition  of  those 
disparate  access  controllers  in  order  to  facilitate  information  sharing.  Table  12  provides  a 
summary  of  the  contributions  of  the  research  presented  in  this  dissertation. 

The  specific  contributions  of  this  work  are: 

1.  Developed  and  Used  a  New  Methodology  for  Security  Analysis  using 
UML-based  Use  Case  Analysis  to  Direct  the  Re-architecting  of  a 
System  for  the  Preservation  of  Safety 

The  methodology  of  security  analysis  using  UML  Use  and  Misuse  Cases,  allows 
for  tailoring  of  security  policies  and  mitigating  the  “highest  cost”  risks  for  information 
flow  while  still  enabling  trusted  sharing.  UML-based  Use  Case  security  analysis  has  not 
been  applied  in  a  MLS,  SOA-based  venue  and  this  work  utilizes  that  approach  as  an 
exemplar  to  provide  for  a  greater  access  to  information  and  increased  sharing  among 
disparate  security  domains.  In  order  to  support  inviolate  information  flows  to  the  security 
policy,  and  to  overcome  the  tranquility  property  associated  with  traditional  MLS  systems, 
we  demonstrate  that  Radiant  Alloy  needs  to  use  an  information  declassifier. 
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Contribution 

❖  Provide  a  method  for 
security  analysis  using 
UML  Use  Case  Analysis 
to  direct  the  re¬ 
architecting  of  a  system 
for  the  preservation  of 
safety. 

❖  Incorporate  a  process 
to  allow  for  the 
prioritization  of 
information  flows  and  the 
“safe”  composition  of 
mixed  access  control 
models. 

<♦  Create  business 
process  mles,  using 
RuleML  to  specify 
allowed  information 
flows  and  to  restrict 
flows  that  enable 
leakage  of 
information  from 
emergent  behaviors, 
and  facilitate  sharing 
between  systems. 

Validation  of  the 
system  re-architecting 
through  the  conduct  of 
a  Regression  Test  to 
provide  verification  of 
RuleML  content  based 
query  injection  and 
filtering. 

Impact  to 
DOD 

*t*  Allows  for  tailoring 
security  policies  and 
mitigating  the  “highest 
cost”  risks  for 
information  flow  while 
still  enabling  tmsted 
sharing. 

Opens  the  information 
sharing  infrastmcture  to 
more  DOD  organizations. 

❖  Allow  greater 
control  of  Need  to 
Share  /  Need  Not  to 
Share  information 
within  domains. 

<♦  Increase  speed  of 

information 

dissemination. 

❖  Address  high 
tempo  of  battle  and 
change  in  situation  for 
MDA  instances. 

*1*  Build  basis  of 
confidence  for  services 
use/reuse  with  respect 
to  the  Information 
Broker  and  its 
associated  mle  engine. 

❖  Build  basis  of 
confidence  for  services 
use/reuse  with  respect 
to  the  Information 
Broker  and  its 
associated  mle  engine. 

♦♦♦  Utilizes  a  process  in  a 
new  domain  and  to 

<♦  Extends  an  open- 

<♦  Automatically 

provide  for  a  greater 

source,  XML-based, 

provide  Information 

granularity  of  access  to 

business  process 

Broker  web  services  a 

Impact  to 

information. 

language  to 

means  of  information 

Software 

❖  Allows  engineers  and 

facilitating  the 

sharing  and 

Engineering 

composition  of  access 

information  filtering 

developers  to  combine 

controllers  and  the 

that  is  not  available 

“best  of’  practices  in 

safety  of  the 

within  individual 

their  design  of  an 

associated  models. 

access  control  models. 

information  system. 

Table  12.  Research  Contribution  Summary 
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2.  Developed  a  New  Process  to  Allow  for  the  Prioritization  of 
Information  Flows  and  the  “Safe”  Composition  of  Mixed  Access 
Control  Models  through  a  Re-architecting  of  the  System 

Through  the  process  of  prioritizing  the  information-flow  needs  within  a  system, 
we  can  tailor  the  composition  of  different  access  control  models  to  support  required 
flows.  This  effectively  opens  the  information  sharing  infrastructure  to  more  DOD 
organizations  and  provides  a  means  for  cooperation  and  more  real-time  passing  of 
information  between  agencies.  This  process  also  helps  engineers  and  developers  combine 
“best-of’  practices  in  their  design  and  implementation  of  an  AIS.  The  idea  of 
prioritization  is  based  on  the  risk  analysis  and  risk  tolerances  of  the  stakeholders.  The 
allowable  “exceptions”  to  our  baseline  policies  are  considered  as  the  only  permissible 
extensions  and  ultimately  determine  what  is  safe  for  the  system.  The  method  shown  in 
this  research  uses  RuleML  to  enforce  this  policy.  The  need  for  sharing  and  the  need  to 
maintain  security  must  be  balanced  to  provide  an  operationally  useful  system  that  will 
still  uphold  the  desired  and  specified  safety  for  information  flows. 

3.  Created  a  New  Process  for  the  Development  of  Business  Process 
Rules,  using  RuleML  to  Specify  Allowed  Information  Flows  and  to 
Restrict  Flows  Enabling  Leakage  of  Information  from  Emergent 
Behaviors  and  Facilitate  Sharing  between  Information  Systems 

To  support  the  development  of  an  information  declassifler,  we  provide  a  policy- 
based  framework  to  do  so  using  RuleML  [15].  By  developing,  implementing  and 
enforcing  business  process  rules  through  the  use  of  RuleML,  we  realize  a  greater  control 
of  our  information  flows.  The  rule  engine  provides  for  a  greater  granularity  of  Need  (Not) 
to  Share  for  information  within  domains,  facilitating  the  dissemination  of  information  and 
providing  increased  speed  of  information  flow  to  allow  a  greater  use  of  “real-time” 
information,  compared  with  traditional  MAC-only  policies.  Current  systems  cannot 
support  this  level  of  information  sharing  and  traditionally  use  a  workaround  (i.e., 
sneakernet)  to  meet  user  requirements.  The  extension  of  an  open-source  XML-based 
business  process  language  to  facilitate  the  composition  of  access  controllers  and  the 
safety  of  the  associated  models  provides  a  useful  tool  for  software  engineers  in  system- 
architecting  efforts. 
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4. 


Provided  a  Process  that  Allows  Engineers  to  use  Decision  Tables  or 
Other  Methods  to  Develop  Simple  Propositions  to  Express  Desired 
Process  and  Information  Flows  that  can  be  Formed  into  Executable 
RuleML 

With  the  re-architecting  of  an  information  system,  it  is  necessary  to  provide  a 
convincing  argument  that  the  RuleML  specification  supports  the  system’s  required 
information  flows.  By  creating  business  process  rules  with  RuleML  to  support  the 
sharing  of  information  within  the  system,  we  can  show  that  all  prior  capabilities  and 
intended  flows  are  still  available  to  the  user,  yet  there  are  no  unintended  flows  that  result 
in  violation  of  the  safety  property.  This  is  an  extension  of  the  work  conducted  on  the 
hook-up  theorem  for  multilevel  security  with  respect  to  inference  control  and  the 
composability  of  restrictiveness  for  security  policies  [41].  This  must  be  done  to  build  a 
basis  of  confidence  for  services  to  be  used  (and  reused)  with  respect  to  the  Information 
Broker  and  its  associated  rule  engine  based  Information  Declassifier  service.  By 
regression  testing,  which  includes  running  the  ruleset  with  a  sample  data  set,  we  can 
verify  that  our  security  use  case  is  correct.  This  is  necessary  to  help  establish  a  basis  for 
certification  of  information  systems  at  high  assurance  levels.  The  rule-based.  Information 
Declassifier  service  helps  to  automatically  provide  Information  Broker  web  services  with 
a  means  of  information  sharing  and  information  filtering  that  is  not  available  within 
individual  access  control  models,  and  to  ensure  the  safety  of  information  flows  in  mixed 
model  access  control  systems.  This  included  the  validation  of  the  concept  system  re¬ 
architecting  through  the  conduct  of  a  regression  testing  verification  and  a  simulation  of 
RuleML  content-based  query  injection  and  filtering,  whose  results  verified  the  rule 
structure  and  usage  of  RuleML  as  a  specification  language. 

B.  FUTURE  WORK 

Research  and  engineering  development  remains  to  be  done  to  provide  for  the 
seamless  integration  of  disparate  domain,  mixed  model  access  control  information 
systems  with  high  assurance  information  sharing  as  we  envision.  RuleML  provides  a 
technically  feasible  way  of  specifying  cross-domain  information  flow  control  policies  and 
for  implementing  an  information  declassifier,  but  work  remains  to  be  done  to  fully 
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explore  how  to  leverage  the  power  of  RuleML.  In  addition,  there  are  many  specialty  areas 
that  attempt  to  use  cross-domain  solutions  for  integration  of  repositories  and  information 
sharing.  While  each  of  these  potential  areas  offers  great  potential,  much  of  the  realization 
involves  the  willingness  to  partner  and  share  between  disparate  organizations,  and  hence 
the  solution  to  the  problem  cannot  be  purely  technical. 

1.  Malware  and  Advanced  Persistent  Threat  Correlation 

Malware  has  become  a  pervasive  element  in  computing  today  and  a  key  element 
in  gaining  access  to  a  protected  network.  The  hardest  threat  to  defend  becomes  the 
advanced  persistent  threat  (APT),  which  is  typically  state-sponsored.  This  APT  is 
resourced,  well-trained,  and  active  in  state-sponsored  entities.  The  effort  to  defend  an 
enterprise  network  against  these  threats  and  the  services  being  offered  to  assist  in  this 
process  are  continually  growing.  The  resources  required  to  defend  against  malware  and 
hackers  in  terms  of  monetary  and  overall  resource  cost,  time,  and  scope  of  effort  have 
increased  dramatically  each  year  and  the  expertise  of  the  APT  heightens  this  effort  even 
more.  The  effort  is  asymmetrical,  where  the  defender  has  to  determine  what  to  defend 
and  how  to  defend  against  an  infinite  (in  theory)  number  of  possible  attacks,  but  the 
attacker  only  has  to  find  one  or  a  few  exploitable  vulnerabilities  in  order  to  exploit  the 
network  security.  While  the  government  and  private  industry  have  gone  in  different 
directions  with  tracking  and  reporting  efforts,  the  defense  techniques,  the  threat  activity, 
and  threat  actors  are  the  same.  Several  challenges  exist,  ranging  from  political,  legal,  and 
policy  (e.g.,  antitrust  laws)  that  must  be  overcome  before  technical  solutions  can  be 
applied.  By  enabling  information  sharing  and  integration  of  disparate  tracking  efforts,  we 
could  realize  an  economy  of  scale  in  these  defense  efforts,  as  well  as  provide  much  better 
intelligence  against  these  known  threats. 

The  Department  of  Defense  (DOD)  and  Department  of  Homeland  Security  (DHS) 
established  a  voluntary  sharing  program  for  cyber  incidents  with  many  industry  partners. 
This  is  referred  to  as  the  Defense  Information  Base  (DIB)  and  consists  of  companies  such 
as  Northrop  Grumman,  Raytheon,  and  Boeing.  These  DIB  participant  companies  have  a 
strong  partnership  for  threat  detection  and  incident  sharing  among  themselves,  but  they 
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are  only  given  limited  scope  information  from  government  sources  like  the  Federal 
Bureau  of  Investigation  (FBI),  and  the  National  Security  Agency  (NSA)  that  affords  them 
contextual  insight  within  their  own  monitoring  and  network  defense  practices.  However, 
this  effort  does  not  allow  for  disclosure  of  key  elements  that  would  save  time,  effort,  and 
financial  resources  among  the  partners.  Additionally,  these  same  partners  are  conducting 
reverse  malware  analysis  and  reporting  on  the  details  of  the  threats  and  malware 
encountered  within  their  networks,  yet  the  DOD  and  DHS  systems  and  policies  do  not 
currently  support  that  level  of  bi-directional  sharing.  By  reducing  the  scope  and  limiting 
the  details,  these  DIB  partners  are  being  subject  to  and  penetrated  by  cyber  threats  that 
could  be  avoided  with  additional  sharing.  Much  of  the  analysis  of  the  threats  is  redacted, 
as  are  the  pseudonyms  used  between  government  and  DIB  partners.  This  is  the  primary 
cause  of  duplication  of  effort  and  a  much  slower  response  and  reaction  time  to  realized 
threats  for  U.S.  national  security. 

By  enacting  a  trusted  sharing  system  with  an  information  broker  and  an 
information  declassifier  as  described  in  this  research,  this  partnership  could  be  greatly 
enhanced  without  risk  of  exposing  need-not-to-share  type  information  across  non¬ 
government  partners  and  between  DIB  member  companies.  The  research  opportunity  for 
synchronizing  the  disparate  tracking  repositories  for  known  malware  and  how  that  could 
be  better  shared  through  trusted  connectors  and  an  established  RuleML-based  security 
policy  could  have  a  significant  effect  on  the  DOD  and  private  industry. 

2.  Distribution  of  Services  and  Rule  Sourcing 

Our  research  considers  a  localized  RuleML  ruleset.  This  ruleset  was  not 
established  as  a  service,  but  only  tested  for  viability  as  a  potential  information  flow 
policy  specification  language  for  the  implementation  of  the  Information  Declassifier.  One 
of  the  most  needed  areas  to  be  covered  as  an  extension  of  this  work  is  for  a  full-scale 
implementation.  This  implementation  should  include  distributed  services  and  distributed 
rule  sourcing.  The  work  should  replicate  the  services  of  a  SOA  system  and  have  rules 
access  different  services  for  firing  and  decisions.  Our  work  replicated  the  sourcing  of  user 
attributes  during  rule  evaluation  and  execution,  yet  this  is  an  area  of  great  concern  for  a 
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MLS  ID.  This  would  be  useful  in  a  distributed  environment  and  give  a  viable  argument 
for  information  releasability  being  safe.  The  full-scale  system  should  include  a 
distribution  and  versioning  of  the  de-classification  policies  in  which  every  agent  runs  its 
own  policy  and  calls  the  other  one  for  the  appropriate  invocation  of  rules.  This  way  each 
agent  only  exposes  those  aspects  of  the  policy  that  they  are  permitted  to  expose.  One  risk 
associated  with  this  distribution  and  remote  sourcing  of  rules  is  with  failure  and 
divergence.  When  we  begin  to  rely  on  externally  sourced  services  to  provide  input  for 
rule-evaluation,  we  risk  that  the  service  will  hang  while  waiting  for  a  response.  This 
response  may  be  delayed  somewhere  in  the  network,  or  even  worse,  the  response  may  be 
a  circular  reference  and  be  dependent  on  the  same  service  that  had  invoked  it  for  part  of 
its  evaluation.  This  dependency  on  variables  sourced  in  other  rules  or  other  services  for 
successive  calls  is  an  area  that  also  needs  to  be  addressed  as  a  function  of  the  distribution 
of  rule  sourcing  and  the  full  implementation  of  services.  The  replication  of  the  ID  needs 
to  be  done  in  tandem  with  sharing  the  ruleset  that  is  created  between  IB  domains.  Since 
the  IB  is  replicated  and  the  ID  will  be  replicated,  an  issue  can  arise  in  which  the  ruleset 
becomes  out  of  synch  and  the  rules  from  a  higher  level  are  not  the  same  as  the  rules  from 
the  lower,  since  we  need  to  evaluate  different  risks  at  disparate  domain  levels. 
Additionally,  the  vessel  information  that  is  processed  could  be  sourced  from  a  working 
U.S.  Navy  system  like  MASTER.  This  system  integrates  vessel  data  with  the  MIEM  and 
could  easily  populate  a  query  with  real  data.  The  MIEM  schemas  can  also  allow  for  a 
finer  granularity  of  rule  based  on  other  viable  vessel  data  fields.  Ultimately,  the 
distributed  system  version  would  play  favorably  toward  a  true  and  expressed  need  in  the 
DOD  and  Homeland  Defense  communities  [5]. 

3.  Using  RuleML  for  a  CDS  Data  Sanitization  Policy 

There  are  many  venues  where  this  effort  can  help  to  realize  the  information 
sharing  needs  of  multiple  organizations.  In  particular,  we  often  need  to  focus  on  the 
releasability  of  information  and  not  just  injection  or  filtering.  One  of  the  areas  where  this 
research  work  can  be  extended  is  data  sanitization  between  domains.  This  methodology 
and  development  of  rules  can  be  tailored  to  meet  the  business  process  needs  in  just  such  a 

manner.  Oftentimes  federal  agencies  are  tasked  to  work  with  state  and  local  agencies  to 
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conduct  drag  enforcement  or  other  speeial  operations.  Such  scenarios  provide  fertile 
ground  for  exploring  information  releasability  and  the  use  of  a  sanitizer.  Usually  when 
working  with  the  DOD,  a  state  and  loeal  ageney  will  provide  information  to  the  DOD.  By 
our  current  polieies  and  elassification  marking  system,  as  soon  as  the  DOD  ageney 
obtains  that  information,  it  beeomes  elassified  at  a  higher  level  than  what  we  can  release 
back  to  the  state  or  local  agency.  This  is  similar  to  the  seenario  we  worked  with  in  our 
research,  yet  the  primary  reason  the  DOD  is  involved  is  to  support  the  state  and  loeal 
agencies  and  not  the  other  way  around.  In  this  case,  we  may  be  able  to  sanitize  certain 
fields  (using  XML  tags)  of  data  that  DOD  eannot  release  baek  to  the  state  or  loeal 
agency.  But,  if  we  look  at  the  origination  of  the  data  and  the  mission  seenario,  we  should 
be  able  to  tailor  our  raleset  aceordingly  while  preserving  our  ability  to  enforce  our 
seeurity  poliey.  An  additional  area  may  be  the  eonsideration  of  time  in  the  release  of 
information.  When  an  aetion  has  already  oecurred,  what  value  does  the  information  have? 
Adding  a  temporal  eonstraint  or  aspeet  to  a  raleset  would  help  to  enforee  the  time  value 
of  information  and  to  enhance  our  ability  to  share  without  violation  of  policy.  This  would 
raise  the  eomplexity  of  analyzing  the  data  itself  for  queries  and  rale  exeeution,  but  would 
also  help  to  alleviate  the  inevitable  progression  of  data  to  the  high  side  of  our 
classifieation  systems. 

4.  Formal  Patterns  for  Access  Control  Model  Composition 

A  key  area  of  possible  work  exists  with  the  integration  of  disparate  access  eontrol 
models.  This  integration  would  be  served  best  through  the  development  of  a  pattern  for 
how  a  set  of  aecess  eontrol  models  can  be  eombined.  Software  engineering  has  been  the 
benefactor  of  both  design  and  arehiteetural  patterns  for  years  in  the  creation  of  new 
systems.  Patterns  trace  their  origins  baek  to  Alexander’s  work  on  urban  planning  and 
arehitecture,  and  software  patterns  in  particular  were  brought  to  prominenee  in  1994,  with 
the  Gamma,  Helm,  Johnson,  and  Vlissides’s  (the  Gang  of  Four)  book  of  Design  Patterns, 
which  was  geared  toward  objeet  oriented  programming.  [70]  Patterns  are  a  best  praetiee 
approach  to  solving  a  recurring  problem  in  a  particular  domain  or  context.  Design 
patterns  are  a  generalized  approach  to  solving  a  problem  that  must  be  implemented  each 
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time  they  are  used.  These  patterns  are  used  to  address  a  specific  element  of  the  system 
design.  In  [70],  four  essential  elements  of  a  design  pattern  include: 


1 .  A  meaningful  name 

2.  A  description  of  the  problem  to  show  how  and  when  the  pattern  should  be 
applied 

3.  A  solution  description  of  the  parts  of  the  design  solution,  relationships, 
and  responsibilities. 

4.  A  statement  of  consequences  including  the  results  and  the  trade-offs  of 
using  or  applying  the  pattern. 

This  standard  pattern  format,  to  which  we  generally  adhere,  helps  to  explain  and 
document  the  purpose,  intent,  consequences,  and  other  referencing  patterns.  Each  pattern 
discussion  includes;  intent,  motivation,  applicability,  structure,  participants, 
collaborations,  consequences,  implementation,  sample  code,  known  uses  and  related 
patterns.  Patterns  can  be  used  to  describe  a  system  structure  that  meets  the  design  needs 
of  an  application  in  a  given  domain.  Almost  as  a  tribal  knowledge  is  passed  along,  the 
pattern  use  and  standardized  format  allow  for  an  easy  to  use  and  robust  set  of  information 
about  rationale,  consequences,  and  related  decisions  for  system  design.  The  pattern  also 
allows  for  a  faster  method  of  documentation,  since  many  of  the  aspects  of  “good” 
documentation  are  included  in  the  original  pattern  description.  This  type  of 
documentation  for  the  composition  of  disparate  access  controllers  could  be  of  tremendous 
benefit  to  the  security  personnel  tasked  with  integrating  multiple  systems. 

A  key  benefit  to  pattern  use  is  the  ability  to  tailor  the  purpose  of  the  pattern  to 
meet  differing  quality  aspects  or  critical  requirements,  such  as:  performance,  security, 
safety,  availability,  reliability,  maintainability,  or  dependability.  Inherent  with  this 
focused  approach  to  maximizing  or  targeting  one  aspect  is  that  the  others  are,  of  course, 
affected.  This  affect  may  be  positive  (e.g.,  security  is  patterned,  but  safety  is  also 
enhanced)  or  negative  (e.g.,  security  is  patterned,  but  performance  is  degraded).  By 
utilizing  the  idea  of  patterns  in  our  composition  of  access  control  models  we  can  afford 
system  and  security  policy  designers  the  ability  to  rapidly  create  security  policies  that 
will  work  well  together  and  make  transparent  the  engineering  tradeoff  decisions  that  need 
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to  be  made.  The  ereation  of  an  ID  service  and  its  associated  ruleset  using  a  pattern  to  seed 
the  development  is  ideal.  The  composition  pattern  should  probably  include  areas  where 
the  access  control  models  conflict  between  themselves,  the  overall  information  flows  and 
recommendations  for  how  those  conflicts  can  and  should  be  resolved.  Any  ambiguity  in  a 
ruleset  is  bad.  The  pattern  idea  extended  to  the  ID  ruleset  can  allow  for  conflict-of- 
interest  mitigation  (i.e.,  using  rules  to  decide  between  conflicts)  between  systems  using 
differing  access  control  models  that  are  required  to  share  information  seamlessly.  If  we 
continue  to  rely  on  the  best  efforts  of  those  who  are  designing  a  system  and  trying  to 
integrate  disparate  policies  without  such  a  template,  then  we  risk  that  policy  being 
unsound  or  incomplete. 

This  patterning  would  also  allow  for  a  repeatable  methodology  for  misuse/breach 
of  the  safety  property  between  disparate  controllers.  Ultimately,  we  face  a  compromise 
between  the  effectiveness  of  our  security  mechanisms  and  controls  and  the  operational 
effectiveness  of  the  system.  A  pattern  approach  to  provide  a  baseline  for  the  mandated 
policy  specified  with  RuleML  (for  the  Information  Declassifier)  would  help  to  meet  our 
need  for  information  sharing. 

5.  RBAC  for  Mandatory  Access  Control  of  Query  Sets 

Developing  RBAC -based  permissions  for  queries  to  the  system  and  even  rules 
based  upon  roles  for  within  a  specific  domain  is  a  promising  area  for  further  research.  By 
using  role-based  permissions  on  a  set  of  queries  (i.e.,  a  single  query  or  a  group  of  n 
queries)  assigned  to  a  particular  role.  This  would,  in  effect,  limit  the  scope  of  queries  by 
what  role  the  user  plays  in  the  system  and  also  add  a  greater  granularity  with  the  access 
control  assisting  the  information  declassifier  to  fulfill  its  duties.  This  would  leverage  the 
usefulness  of  RBAC,  where  we  do  not  need  to  change  the  role-permission  mappings  very 
often.  Instead,  we  merely  change  the  user-role  mappings  for  our  system.  If  we  could  map 
a  set  of  queries  as  just  another  object  in  the  system,  then  the  role  could  be  given  specific 
access  to  that  object  (i.e.,  a  restricted  set  of  queries).  Then  the  Information  Declassifier 
that  we  have  described  in  this  work  would  still  be  used  to  filter  and  inject  information 
between  domains.  For  example,  a  Harbormaster  would  be  given  query  ability  for  two  to 
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three  queries  and  RuleML  eould  be  used  to  further  filter  those  role-based  queries  for 
loeation  (e.g.,  the  role-based  query  allows  for  queries  about  ships  inbound  and  outbound 
for  any  harbormaster  to  use,  but  the  San  Diego  HM  only  gets  results  for  San  Diego  as 
filtered  by  the  ID).  Additionally,  we  could  utilize  web  services  to  invoke  separate  IDs 
based  on  the  role-permission  mapping  by  changing  the  port  and  addressing  of  the 
individual  queries  based  on  the  role  the  user  is  performing.  This  would  allow  for  a  more 
structured  filtering  ability,  yet  it  would  add  to  the  complexity  of  designing  numerous 
rulesets  for  multiple  ID  services  at  the  same  classification-domain  level. 

6.  Automatic  Generation  of  Cover  Stories 

The  use  of  obfuscation  through  polyinstantiation  to  prevent  inference  attacks  and 
general  inference  from  authorized  use  is  well  known.  Another  area  where  a  RuleML 
application  of  policy  could  be  implemented  is  with  the  automatic  generation  of  cover 
stories  to  promote  data  hiding.  By  allowing  the  automatic  generation  the  system  will  not 
continue  to  produce  the  same  consistent  result  from  a  query  or  interaction.  This  will  also 
prevent  the  ability  to  infer  information  from  the  system  from  both  the  lack  of  information 
presented  and  from  the  presence  of  known  invalid  information. 
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APPENDIX  A.  RULESET  EXPLICATION 


RulelD  0  is  titled  Alert  Not  Valid  for  Role  Location.  This  rule  is  intended  to 
eliminate  possibilities  for  Alert  Messaging  responses  that  are  not  valid  for  our  seenario.  If 
an  Alert  exists  for  Los  Angeles  in  the  system  (at  a  higher  level  IB),  then  this  rule  turns 
that  notifieation  to  FALSE,  sinee  it  does  not  apply  to  the  port  of  San  Diego. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Alert  Not  Valid  for  Role  Location</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy  Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>3/10/2009</ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<ind 

uri="#inf ormation_Declassif ier "  /> 

</scope> 

<oid>ruleO</ oid> 

<! --Alert  Not  Valid  for  Role  Location--> 

<if> 

<0r> 

<0r> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notif ication</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 
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type="string">"Alert  Exists  (SECRET  IB)  for  Port  of 

Los  Angeles"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Noti float ion</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (TS  IB)  for  Port  of  Los 

Angeles "</Ind> 

</rhs> 

</Equal> 

</0r> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Noti float ion</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"No  Alert  Exists"</Ind> 

</rhs> 

</Equal> 

</0r> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</Rule> 


Listing  1 1 .  RuleML  code  for  RulelD  0 

RulelD  1  is  titled  Alert  Notification  is  Present.  This  rule  is  intended  to  set  the 
variable  Query _Requires_Data_Insertion  to  TRUE,  if  the  higher  level  IB  possesses  an 
Alert  Message.  In  this  ruleset,  the  external  reference  is  not  made,  but  invoked  through  the 
use  of  an  internally  generated  variable  for  the  sourcing. 

<Rule 

style=" active" 
evaluation="strong"> 
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<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Alert  Notification  is  Present</Ind> 
</Fun> 

</Fxpr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>2/26/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 

</scope> 

<oid>rulel</oid> 

<! --Alert  Notification  is  Present--> 

<if> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">true</Ind> 

</rhs> 

</Equal> 

</if> 

<do> 

<Atom> 

<Rel>Query_Requires_Data_Insertion</Rel> 
<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 

Listing  12.  RuleML  code  for  RulelD  1 
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RulelD  2  is  titled  Est  Location  for  Role.  This  rule  is  intended  to  fix  the  assignment  of  the 
user’s  role  location  to  the  results  being  returned  from  the  IB.  This  will  allow  for 
additional  filtering  to  match  the  user’s  location  with  vessel  results  from  the  data 
repositories  that  match  with  origination  or  destination  ports. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Est  Location  for  Roie</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy  Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 
<ind>3/5/2009</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassif ier "  /> 
</scope> 

<oid>ruie2</ oid> 

<!--Est  Location  for  Roie--> 

<if> 

<Or> 

<Equai> 

<ihs> 

<Atom> 

<Rei>Location</Rei> 

<Var>Sub j  ect</Var> 

</Atom> 

</ihs> 

<rhs> 

<ind 

type="string">"Oakiand"</ind> 

</rhs> 

</Equai> 

<Equai> 

<ihs> 
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<Atom> 

<Rel>Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"San  Diego "</Ind> 
</rhs> 

</Equal> 

</0r> 

</if> 

<do> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

<Atom> 

<Rel>Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 


Listing  13.  RuleML  code  for  RulelD  2 


RulelD  3  is  titled  IB  Results  0.  This  is  one  of  the  ten  IB  results  rules  that  is  intended  to 
replicate  the  results  from  an  actual  IB.  It  is  used,  based  on  the  variables  it  is  sourced  with 
to  provide  an  expected  result  when  testing  the  rule  base  with  a  sample  query.  In  this  case, 
it  returns  the  IB  result  of  “Vessel  Results  from  Unclassified  IB  with  ID  Injection  for 
Oakland  Alert.”  This  is  done  after  checking  the  user’s  security  level  and  for  the  presence 
of  an  alert  for  this  location.  This  rule  was  created  to  allow  for  Harbormaster  queries  from 
the  port  of  Oakland  as  an  extension  to  the  San  Diego  port  accounted  for  in  our  scenario. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>IB  Results  0</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 
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<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 

</scope> 

<oid>rule3</ oid> 

Results  0--> 

<if> 

<And> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notif ication</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (TS  IB)  for  Port  of 

Oakland"</Ind> 

</rhs> 
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</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"Vessel  Results  from  Unclassified  IB  with  ID 
injection  for  Oakland  Alert"</ind> 

</Atom> 

</do> 

</Rule> 


Listing  14.  RuleML  code  for  RulelD  3 


RulelD  4  is  titled  Oakland  Harbormaster  query  is  valid  destination.  This  is  one  of  the 
rules  used  as  extension  to  our  primary  scenario,  which  would  allow  for  the  port  of 
Oakland  queries  to  also  work  in  the  system.  It  is  used  to  verify  the  user  role,  the  role 
location,  the  PDF  decision,  and  the  type  of  query  before  deciding  that  it  is  a  valid  query 
and  should  be  processed  by  the  IB. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<ind>Oakland  Harbormaster  query  is  valid 
destination</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy  Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>3/5/200  9</ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<ind 
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uri="#Inf ormation_Declassif ier "  / > 

</scope> 

<oid>rule4</ oid> 

<! --Oakland  Harbormaster  query  is  valid  destination--> 
<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Harbormaster"</lnd> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Oakland"</lnd> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Re 1 >HM_Que  r ies</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="s bring" >"Destination_Port  Query"</ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 
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<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif ication_Level</Rel> 
<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Destination_Port</Rel> 
<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 


Listing  15.  RuleML  code  for  RulelD  4 

RulelD  5  is  titled  PDP  Decision.  This  is  an  externally  sourced  rule  that  would  be 
completed  by  the  Policy  Decision  Point  service  in  our  SOA  system.  It  is  used,  based  on 
the  variables  it  is  sourced  with,  to  provide  a  decision  for  that  user’s  access  to  resources  in 
the  system.  In  this  implementation,  it  is  not  referenced  from  an  actual  external  PDP 
service. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>Policy  Decision  Point</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy  Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 
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uri="dc : date"> 
<Ind>2/26/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 
</scope> 

<oid>rule5</ oid> 

<! --Policy  Decision  Point--> 

<if> 

<Equal> 

<lhs> 

<Atom> 

<  Re 1 >U  s  e  r_Ro 1 e_Pe  r mi ssions</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<ind 

type="bool">true</ind> 

</rhs> 

</Equal> 

</if> 

<do> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

<ind 

type="bool">true</ind> 

</Atom> 

</do> 

</Rule> 


Listing  16.  RuleML  code  for  RulelD  5 


RulelD  6  is  titled  Positive  ID  Response  to  IB  for  Alert.  This  rule  is  used  to  indicate  a 
positive  response  to  the  presence  of  an  Alert  Message  at  a  higher  level  IB  and  verifies 
that  the  query  to  the  IB  is  valid  based  on  the  roles  active  in  our  system.  This  rule  ensures 
that  the  IB  response  that  was  previously  returned  directly  to  the  user  is  now  processed 
through  the  ID  and  missing  data  is  injected  to  the  query  if  necessary,  to  eliminate  the 
Misuse  Case  and  as  a  <Prevent>  feature  of  our  Security  Use  Case.  This  rule  is  designed 
to  verify  other  rules  that  determine  if  the  query  to  the  system  is  valid,  and  if  the  response 
from  the  higher  level  IB  requires  the  system  to  inject  data  before  processing  the  query 
response.  It  also  checks  if  the  query  requires  data  insertion,  which  is  sourced  from  the 
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higher  level  IBs.  If  both  of  these  conditions  are  TRUE,  then  the  IB  that  received  the  query 
is  informed  that  its  response  to  the  user  must  wait  for  the  injection  messaging  from  the  ID 
service  prior  to  returning  results  to  the  user. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Positive  ID  Response  to  IB  for  Alert</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>I2/5/2008</Ind> 

</Fun> 

</Expr> 

</Plex> 

</labeI> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 

</scope> 

<oid>rule6</ oid> 

<! --Positive  ID  Response  to  IB  for  AIert--> 

<if> 

<And> 

<Atom> 

<ReI>VaIid_Query</ReI> 

<Var>Sub j  ect</Var> 

</Atom> 

<Atom> 

<ReI>Query_Requires_Data_Insertion</ReI> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<ReI>IB_Response_Wait</ReI> 

<Var>Sub j  ect</Var> 

<Ind 

type="booI">true</Ind> 
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</Atom> 

</do> 

</Rule> 


Listing  17.  RuleML  code  for  RulelD  6 


RulelD  7  is  titled  Query  is  Valid.  This  is  a  fdtering  rule  and  is  used  to  verify  that  the  user 
(EWO  or  Harbormaster)  is  requesting  an  allowable  query.  It  is  sourced  from  two  other 
rules,  which  check  if  the  query  against  each  actor’s  allowable  query  set,  to  determine 
validity. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Query  is  Vaiid</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy  Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 
<ind>3/i0/2009</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassif ier "  /> 
</scope> 

<oid>ruie7</ oid> 

<! --Query  is  Vaiid--> 

<if> 

<Or> 

<Atom> 

<Rei>HM_Vaiid_Query</Rei> 
<Var>Sub j  ect</Var> 

</Atom> 

<Atom> 

<Rei>EWO_Vaiid_Query</Rei> 
<Var>Sub j  ect</Var> 
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</Atom> 

</0r> 

</if> 

<do> 

<Atom> 

<Rel>Valid_Query</Rel> 
<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 


Listing  18.  RuleML  code  for  RulelD  7 


RulelD  8  is  titled  Alert  Notification  is  Absent.  This  rule  is  intended  to  set  the  variable 
Query _Requires_Data_Insertion  to  FALSE,  if  the  higher  level  IB  does  not  possess  an 
Alert  Message.  In  this  ruleset,  the  external  reference  is  not  made,  but  invoked  through  the 
use  of  an  internally  generated  variable  for  the  sourcing. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>Alert  Notification  is  Absent</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy  Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>2/26/2009</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassif ier "  /> 

</scope> 

<oid>ruie8</oid> 

<!--Aiert  Notification  is  Absent--> 
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<if> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">f alse</Ind> 

</rhs> 

</Equal> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Query_Requires_Data_Insertion</Rel> 
<Var>Sub j  ect</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</Rule> 


Listing  19.  RuleML  code  for  RulelD  8 


RulelD  9  is  titled  Alert  SD  Secret  IB.  This  rule  is  used  to  verify  that  when  an  alert  is 
present  at  the  Secret  level  IB,  intended  for  San  Diego,  and  the  requestor  is  at  the 
Unclassified  security  level,  that  the  Alert_Present_Response  is  set  to  TRUE.  This  will 
indicate  to  the  ID  and  IB  that  an  alert  is  present  that  pertains  to  the  user  query,  and  that 
the  user  is  below  the  alert’s  classification  level. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>Alert  SD  Secret  IB</Ind> 
</Fun> 

</Expr> 

<Expr> 
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<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/200  9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 

</scope> 

<oid>rule9</oid> 

<! — Alert  SD  Secret  IB — > 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notif ication</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (SECRET  IB)  for  Port  of 

San  Diego"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 
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<rhs> 

<Ind 

type="string">"Harbormaster  San  Diego"</Ind> 
</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 


Listing  20.  RuleML  code  for  RulelD  9 

RulelD  10  is  titled  EWO  Query  is  Valid.  This  is  a  filtering  rule  and  is  used  to  verify  that 
the  user  fulfdling  the  EWO  role  is  requesting  an  allowable  query.  It  is  checked  against 
the  actor’s  allowable  query  set,  to  determine  validity. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>EWO  query  is  vaiid</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy  Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>3/5/200  9</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassif ier "  / > 
</scope> 
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<oid>rulelO</ oid> 

<!--EWO  query  is  valid--> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<  Re 1 >U  s  e  r _Ro 1 e < / Re 1 > 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"EWO"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top  Secret"</Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>EWO_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<  Re 1 > V esse 1_C lassificatio n_L e ve 1 < / Re 1 > 
<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 


Listing  21.  RuleML  code  for  RulelD  10 
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RulelD  1 1  is  titled  IB  Results  2.  This  is  one  of  the  ten  IB  results  rules  that  is  intended  to 
replieate  the  results  from  an  actual  IB.  It  is  used,  based  on  the  variables  it  is  sourced  with 
to  provide  an  expected  result  when  testing  the  rule  base  with  a  sample  query.  In  this  case, 
it  returns  the  IB  result  of  “Vessel  Results  from  Secret  IB  and  Unclassified  IB  with  ID 
Injection  for  Oakland  Alert.”  This  is  done  after  checking  the  user’s  security  level  and  for 
the  presence  of  an  alert  for  this  location.  The  IB,  in  this  case,  would  return  its  regular 
result  from  both  the  Unclassified  and  Secret  level  IBs  (since  the  user  is  at  the  Secret 
level),  and  then  the  required  Alert  Message  insertion  from  the  TS  IB.  This  rule  was 
created  to  allow  for  Harbormaster  queries  from  the  port  of  Oakland  as  an  extension  to  the 
San  Diego  port  accounted  for  in  our  scenario. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>IB  Results  2</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 
<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 
</scope> 

<oid>rulell</ oid> 

<! — IB  Results  2 — > 

<if> 

<And> 

<And> 
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<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Secret"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notif ication</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (TS  IB)  for  Port  of 

Oakland"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Oakland"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return  IB  Results</Rel> 
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<Var>Sub j  ect</Var> 

<Ind 

type="string">"Vessel  Results  from  Secret  IB  and 
Unclassified  IB  with  ID  Injection  for  Oakland  Alert"</Ind> 
</Atom> 

</do> 

</Rule> 


Listing  22.  RuleML  code  for  RulelD  1 1 


RulelD  12  is  titled  Negative  ID  Response  to  IB  for  Alert.  This  rule  provides  an 
acknowledgment  of  a  negative  result  for  alert  message  presence.  This  is  used  to  trigger 
other  rules  in  the  ruleset  and  to  ensure  that  the  ID  returns  a  result  in  all  cases.  Without 
this  rule,  it  is  possible  for  the  ID  to  return  nothing,  which  allows  for  ambiguity  in  the 
ruleset.  It  checks  if  the  query  requires  data  insertion,  which  is  sourced  from  the  higher 
level  IBs.  If  FALSE,  then  the  IB  that  received  the  query  is  informed  that  its  response  to 
the  user  does  not  need  to  wait  for  the  ID  injection  messaging  prior  to  returning  results  to 
the  user. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Negative  ID  Response  to  IB  for  Alert</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>2/26/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation  Declassifier"  /> 
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</scope> 

<oid>rulel2</oid> 

<! --Negative  ID  Response  to  IB  for  AIert--> 

<if> 

<And> 

<Atom> 

<ReI>VaIid_Query</ReI> 

<Var>Sub j  ect</Var> 

</Atom> 

<EquaI> 

<Ihs> 

<Atom> 

<ReI>Query_Requires_Data_Insertion</ReI> 
<Var>Sub j  ect</Var> 

</Atom> 

</Ihs> 

<rhs> 

<Ind 

type="booI">f alse</lnd> 

</rhs> 

</EquaI> 

</And> 

</if> 

<do> 

<Atom> 

<ReI>IB_Response_Wait</ReI> 

<Var>Sub j  ect</Var> 

<Ind 

type="booI">f alse</lnd> 

</Atom> 

</do> 

</RuIe> 


Listing  23.  RuleML  code  for  RulelD  12 


RulelD  13  is  titled  Oakland  Harbormaster  query  is  valid  destination  2.  This  rule  is 
almost  a  duplicate  of  RulelD  4,  but  is  used  to  support  an  alternative  method  of 
designating  roles.  In  this  case,  if  the  role  is  listed  as  Harbormaster  Oakland,  instead  of  the 
generic  Harbormaster  designation,  then  the  rule  will  process  similarly.  This  is  one  of  the 
rules  used  as  extension  to  our  primary  scenario,  which  would  allow  for  the  port  of 
Oakland  queries  to  also  work  in  the  system.  It  is  used  to  verify  the  user  role,  the  role 
location,  the  PDF  decision,  and  the  type  of  query  before  deciding  that  it  is  a  valid  query 
and  should  be  processed  by  the  IB. 


<RuIe 

style=" active" 
evaIuation="strong"> 
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<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Oakland  Harbormaster  query  is  valid  destination 

2</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 

</scope> 

<oid>rulel3</oid> 

<! --Oakland  Harbormaster  query  is  valid  destination  2--> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster  Oakland"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Destination_Port  Query"</Ind> 
</rhs> 
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</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"Oakland"</Ind> 

</Atom> 

<Atom> 

<  Re 1 > V esse 1_C lassificatio n_L e ve 1 < / Re 1 > 
<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Destination_Port</Rel> 
<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 


Listing  24.  RuleML  code  for  RulelD  13 


RulelD  14  is  titled  PDP  Decision  2.  This  is  an  externally  sourced  rule  that  would  be 
completed  by  the  Policy  Decision  Point  service  in  our  SOA  system.  It  is  used,  based  on 
the  variables  it  is  sourced  with,  to  provide  a  decision  for  that  user’s  access  to  resources  in 
the  system.  In  this  implementation,  it  is  not  referenced  from  an  actual  external  PDP 
service,  and  this  rule  is  intended  to  provide  a  positive  response  to  the  service  check  for  a 
negative  response. 
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<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Policy  Decision  Point  2</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy  Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>2/26/2009</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassif ier "  /> 
</scope> 

<oid>ruiei4</ oid> 

<!--Poiicy  Decision  Point  2--> 

<if> 

<Equai> 

<ihs> 

<Atom> 

<Rei>User_Roie_Permissions</Rei> 
<Var>Sub j  ect</Var> 

</Atom> 

</ihs> 

<rhs> 

<ind 

type="booi">f aise</ind> 

</rhs> 

</Equai> 

</if> 

<do> 

<Atom> 

<Rei>PDP_Decision</Rei> 

<Var>Sub j  ect</Var> 

<ind 

type="booi">f aise</ind> 

</Atom> 

</do> 

</Ruie> 
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Listing  25.  RuleML  code  for  RulelD  14 


RulelD  1 5  is  titled  Query  is  Invalid.  This  is  a  filtering  rule  and  is  used  to  verify  that  the 
user  (EWO  or  Harbormaster)  is  requesting  an  allowable  query.  It  is  sourced  from  two 
other  rules,  which  check  if  the  query  against  each  actor’s  allowable  query  set,  to 
determine  validity.  This  rule  is  intended  to  provide  a  positive  response  to  the  query  check 
in  the  case  of  a  negative  response. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Query  Invalid</Ind> 

</Fun> 

</Fxpr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 
<Ind>3/10/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 
</scope> 

<oid>rulel5</ oid> 

<! --Query  Invalid--> 

<if> 

<0r> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 
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type="bool">true</Ind> 

</ rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>EWO_Valid_Query</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">true</Ind> 

</rhs> 

</Equal> 

</0r> 

</if> 

<do> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</Rule> 


Listing  26.  RuleML  code  for  RulelD  15 


RulelD  16  is  titled  Alert  SD  Secret  IB  2.  This  rule  is  used  to  verify  that  when  an  alert  is 
present  at  the  Secret  level  IB,  intended  for  San  Diego,  and  the  requestor  is  at  the 
Unclassified  security  level,  that  the  Alert _Present_Response  is  set  to  TRUE.  This  will 
indicate  to  the  ID  and  IB  that  an  alert  is  present  that  pertains  to  the  user  query,  and  that 
the  user  is  below  the  alert’s  classification  level.  This  rule  is  equivalent  to  RulelD  9  and  is 
used  to  support  an  alternative  method  of  designating  roles.  In  this  case,  if  the  role  is  listed 
as  the  generic  Harbormaster,  instead  of  the  Harbormaster  San  Diego  designation,  then  the 
rule  will  process  similarly. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>Alert  SD  Secret  IB  2</Ind> 
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</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 

</scope> 

<oid>rulel 6</ oid> 

<! — Alert  SD  Secret  IB  2 — > 

<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Noti float ion</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (SECRET  IB)  for  Port  of 

San  Diego"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 
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<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"San  Diego"</Ind> 
</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 


Listing  27.  RuleML  code  for  RulelD  16 


RulelD  17  is  titled  IB  Results  3.  This  is  one  of  the  ten  IB  results  rules  that  is  intended  to 
replicate  the  results  from  an  actual  IB.  It  is  used,  based  on  the  variables  it  is  sourced  with 
to  provide  an  expected  result  when  testing  the  rule  base  with  a  sample  query.  In  this  case, 
it  returns  the  IB  result  of  “Vessel  Results  from  Secret  IB  and  Unclassified  IB.”  This  is 
done  after  checking  the  user’s  security  level  and  for  the  presence  of  an  alert  for  this 
location.  The  IB,  in  this  case,  would  return  its  regular  result  from  both  the  Unclassified 
and  Secret  level  IB’s  (since  the  user  is  at  the  Secret  level). 


<Rule 

style=" active" 

evaluation="strong"> 

<label> 
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<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>IB  Results  3</Ind> 

</Fun> 

</Fxpr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>2/2  6/2  00  9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 
</scope> 

<oid>rulel7</ oid> 

Results  3--> 

<if> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

<Equal> 

<lhs> 

<Atom> 

<Rel>lB_Response_Wait</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="bool">f alse</lnd> 
</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 
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<Ind 

type="string">"Secret"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"Vessel  Results  from  Secret  IB  and 
Unclassified  IB"</Ind> 

</Atom> 

</do> 

</Rule> 


Listing  28.  RuleML  code  for  RulelD  17 


RulelD  18  is  titled  Oakland  Harbormaster  query  is  valid  origination.  This  rule  is 
supports  an  alternative  method  of  designating  roles.  In  this  case,  if  the  role  is  listed  as 
Harbormaster  Oakland,  instead  of  the  generic  Harbormaster  designation,  then  the  rule 
will  process  similarly.  This  is  one  of  the  rules  used  as  extension  to  our  primary  scenario, 
which  would  allow  for  the  port  of  Oakland  queries  to  also  work  in  the  system.  It  is  used 
to  verify  the  user  role,  the  role  location,  the  PDF  decision,  and  that  the  query  type  is  for 
an  Originating  Port  before  deciding  that  it  is  a  valid  query  and  should  be  processed  by  the 
IB. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Oakland  Harbormaster  query  is  valid 
origination</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 
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<Fun 

uri="dc : date"> 

<Ind>3/5/200  9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 

</scope> 

<oid>rulel8</oid> 

<! --Oakland  Harbormaster  query  is  valid  origination--> 
<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Harbormaster  Oakland"</lnd> 
</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Originating_Port  Query"</lnd> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<lnd 

type="bool">true</lnd> 

</Atom> 

<Atom> 
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<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"Oakland"</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif ication_Level</Rel> 
<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Originating_Port</Rel> 
<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 


Listing  29.  RuleML  code  for  RulelD  18 


RulelD  19  is  titled  Alert  SD  TS  IB.  This  rule  is  established  as  a  trigger  within  the  ruleset 
to  identify  that  an  Alert  Message  is  present  and  to  verify  the  level  of  the  Alert  Message 
against  the  security  level  of  the  user  producing  the  query.  This  rule  is  used  to  verify  that 
when  an  alert  is  present  at  the  Top  Secret  level  IB,  intended  for  San  Diego,  the  requestor 
is  at  the  Unclassified  or  Secret  security  level,  and  that  the  Alert _Present_Response  is  set 
to  TRUE.  This  will  indicate  to  the  ID  and  IB  that  an  alert  is  present  that  pertains  to  the 
user  query,  and  that  the  user  is  below  the  alert’s  classification  level. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>Alert  SD  TS  IB</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 
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<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 

</scope> 

<oid>rulel 9</ oid> 

<! — Alert  SD  TS  IB — > 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Noti float ion</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (TS  IB)  for  Port  of  San 

Diego"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top  Secret"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 
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type="string">"Harbormaster  San  Diego"</Ind> 
</ rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 


Listing  30.  RuleML  code  for  RulelD  19 

RulelD  20  is  titled  EWO  Query  is  Valid  2.  This  is  a  filtering  rule  and  is  used  to  verify  that 
the  user  fulfilling  the  EWO  role  is  requesting  an  allowable  query.  It  is  checked  against 
the  actor’s  allowable  query  set,  to  determine  validity.  This  rule  is  equivalent  to  RulelD 
10,  but  accounts  for  a  different  role  naming  convention.  In  this  case,  the  user’s  role  is 
Electronic  Warfare  Officer,  instead  of  EWO. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>EWO  query  is  vaiid  2</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy  Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>3/5/200  9</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 
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uri="#Inf ormation_Declassif ier "  / > 

</scope> 

<oid>rule2  0</oid> 

<!--EWO  query  is  valid  2--> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Electronic  Warfare  Of f icer"</Ind> 
</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top  Secret"</Ind> 

</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>EWO_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif ication_Level</Rel> 

<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 
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Listing  3 1 .  RuleML  code  for  RulelD  20 

RulelD  21  is  titled  IB  Results  4.  This  is  one  of  the  ten  IB  results  rules  that  is  intended  to 
replicate  the  results  from  an  actual  IB.  It  is  used,  based  on  the  variables  it  is  sourced  with 
to  provide  an  expected  result  when  testing  the  rule  base  with  a  sample  query.  In  this  case, 
it  returns  the  IB  result  of  “Vessel  Results  from  Unclassified  IB.”  This  is  done  after 
checking  the  user’s  security  level  and  for  the  presence  of  an  alert  for  this  location  being 
FALSE.  The  IB,  in  this  case,  would  return  its  regular  result  from  the  Unclassified-level 
IB. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>IB  Results  4</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 
<Ind>2/26/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 
</scope> 

<oid>rule2 !</ oid> 

Results  4--> 

<if> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 
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</Atom> 

<Equal> 

<lhs> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">f alse</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"Vessel  Results  from  Unclassified  1B"</Ind> 
</Atom> 

</do> 

</Rule> 


Listing  32.  RuleML  code  for  RulelD  21 


RulelD  22  is  titled  Oakland  Harbormaster  query  is  valid  origination  2.  This  rule  is 
almost  a  duplicate  of  RulelD  18,  but  is  used  to  support  an  alternative  method  of 
designating  roles.  In  this  case,  if  the  role  is  listed  as  the  generic  Harbormaster,  instead  of 
the  Harbormaster  Oakland  designation,  then  the  rule  will  process  similarly.  This  is  one  of 
the  rules  used  as  extension  to  our  primary  scenario,  which  would  allow  for  the  port  of 
Oakland  queries  to  also  work  in  the  system.  It  is  used  to  verify  the  user  role,  the  role 
location,  the  PDF  decision,  and  the  type  of  query  is  an  originating  port  query  before 
deciding  that  it  is  a  valid  query  and  should  be  processed  by  the  IB. 
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<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Oakland  Harbormaster  query  is  vaiid  origination 

2</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy  Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>3/5/2009</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassif ier "  / > 

</scope> 

<oid>ruie22</oid> 

<!--Oakiand  Harbormaster  query  is  vaiid  origination  2--> 

<if> 

<And> 

<And> 

<And> 

<Equai> 

<ihs> 

<Atom> 

<Rei>User_Roie</Rei> 

<Var>Sub j  ect</Var> 

</Atom> 

</ihs> 

<rhs> 

<ind 

type="string">"Harbormaster"</ind> 

</rhs> 

</Equai> 

<Equai> 

<ihs> 

<Atom> 

<Rei>User_Roie_Location</Rei> 

<Var>Sub j  ect</Var> 

</Atom> 
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</lhs> 

<rhs> 

<Ind 

type="string">"Oakland"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Originating_Port  Query"</Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif ication_Level</Rel> 

<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Originating_Port</Rel> 

<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 


Listing  33.  RuleML  code  for  RulelD  22 
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RulelD  23  is  titled  Alert  SD  TS  IB.  This  rule  is  used  to  verify  that  when  an  alert  is  present 
at  the  Top  Secret  level  IB,  intended  for  San  Diego,  and  the  requestor  is  at  the 
Unclassified  or  Secret  security  level,  that  the  Alert _Present_Response  is  set  to  TRUE. 
This  will  indicate  to  the  ID  and  IB  that  an  alert  is  present  that  pertains  to  the  user  query, 
and  that  the  user  is  below  the  alert’s  classification  level.  This  rule  is  equivalent  to  RulelD 
19  and  is  used  to  support  an  alternative  method  of  designating  roles.  In  this  case,  if  the 
role  is  listed  as  the  generic  Harbormaster,  instead  of  the  Harbormaster  San  Diego 
designation,  then  the  rule  will  process  similarly. 


<Rule 

styles" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Alert  SD  TS  IB  2</Ind> 

</Fun> 

</Fxpr> 

<Fxpr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Fxpr> 

<Fxpr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/200  9</Ind> 

</Fun> 

</Fxpr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 
</scope> 

<oid>rule23</ oid> 

<! --Alert  SD  TS  IB  2--> 

<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notif ication</Rel> 
<Var>Sub j  ect</Var> 
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</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (TS  IB)  for  Port  of  San 

Diego"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top  Secret"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"San  Diego "</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 
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</do> 

</Rule> 


Listing  34.  RuleML  code  for  RulelD  23 


RulelD  24  is  titled  IB  Results  5.  This  is  one  of  the  ten  IB  results  rules  that  is  intended  to 
replicate  the  results  from  an  actual  IB.  It  is  used,  based  on  the  variables  it  is  sourced  with 
to  provide  an  expected  result  when  testing  the  rule  base  with  a  sample  query.  In  this  case, 
it  returns  the  IB  result  of  “Vessel  Results  from  TS  IB,  Secret  IB  and  Unclassified  IB.” 
This  is  done  after  checking  the  user’s  security  level  is  equal  to  Top  Secret.  The  user  in 
this  case  is  authorized  all  data  from  each  of  the  classification  levels  and  does  not  require 
injection  to  the  IB  results. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>IB  Results  5</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 
<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 
</scope> 

<oid>rule2  4</ oid> 

Results  5--> 

<if> 

<And> 

<And> 
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<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

<Equal> 

<lhs> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">f alse</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top  Secret"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"Vessel  Results  from  TS  IB,  Secret  IB,  and 
Unclassified  IB"</Ind> 

</Atom> 

</do> 

</Rule> 


Listing  35.  RuleML  code  for  RulelD  24 


RulelD  25  is  titled  SD  Harbormaster  query  is  valid  destination.  This  rule  is  used  to  verify 
the  user  role  as  Harbormaster,  the  role  location  is  San  Diego,  the  PDF  decision  is  TRUE, 
and  the  query  is  both  valid  and  of  the  type  Destination  Port  Query  before  deciding  that 
it  is  valid  and  should  be  processed  by  the  IB. 

<Rule 

style=" active" 
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evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>SD  Harbormaster  query  is  valid  destination</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 

</scope> 

<oid>rule25</ oid> 

<!--SD  Harbormaster  query  is  valid  destination--> 

<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"San  Diego "</Ind> 
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</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Destination_Port  Query"</Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<  Re 1 > V esse 1_C lassificatio n_L e ve 1 < / Re 1 > 

<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Destination_Port</Rel> 

<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 


Listing  36.  RuleML  code  for  RulelD  25 


RulelD  26  is  titled  Alert  Oak  Secret  IB.  This  rule  is  established  as  a  trigger  within  the 
ruleset  to  identify  that  an  Alert  Message  is  present  and  to  verify  the  level  of  the  Alert 
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Message  against  the  security  level  of  the  user  producing  the  query.  This  particular  rule  is 
used  as  an  extension  to  our  baseline  scenario  to  account  for  users  at  the  port  of  Oakland. 
This  will  indicate  to  the  ID  and  IB  that  an  alert  is  present  that  pertains  to  the  user  query, 
and  that  the  user  is  below  the  alert’s  classification  level. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Alert  Oak  Secret  IB</Ind> 

</Fun> 

</Fxpr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 

</scope> 

<oid>rule2  6</oid> 

<! --Alert  Oak  Secret  IB--> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notif ication</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (SECRET  iB)  for  Port  of 

Oakland"</ind> 

</rhs> 

</Equal> 
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<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster  Oakland"</Ind> 
</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 


Listing  37.  RuleML  code  for  RulelD  26 


RulelD  27  is  titled  IB  Results  6.  This  is  one  of  the  ten  IB  results  rules  that  is  intended  to 
replicate  the  results  from  an  actual  IB.  It  is  used,  based  on  the  variables  it  is  sourced  with 
to  provide  an  expected  result  when  testing  the  rulebase  with  a  sample  query.  In  this  case, 
it  returns  the  IB  result  of  “Invalid  Query!.”  This  is  done  after  checking  the  query  validity 
from  the  Valid  Query  variable. 


<Rule 

style=" active" 

evaluation="strong"> 

<label> 

<Plex> 
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<Expr> 

<Fun 

uri="dc : title"> 

<Ind>IB  Results  6</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 
</scope> 

<oid>rule27</oid> 

Results  6--> 

<if> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="bool">f alse</lnd> 

</rhs> 

</Equal> 

</if> 

<do> 

<Atom> 

<Rel>Return_lB_Results</Rel> 

<Var>Sub j  ect</Var> 

<lnd 

type="string">"lnvalid  Query! "</lnd> 
</Atom> 

</do> 

</Rule> 


Listing  38.  RuleML  code  for  RulelD  27 
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RulelD  28  is  titled  SD  Harbormaster  query  is  valid  destination  2.  This  rule  is  identieal  in 
funetionality  to  RulelD  25,  but  supports  the  extended  role  convention  using 
Harbormaster  San  Diego  instead  of  the  generic  Harbormaster  role.  This  rule  is  used  to 
verify  the  user  role  as  Harbormaster  San  Diego,  the  PDP  decision  is  TRUE,  and  the  type 
of  query  is  Destination  Port  Query  before  deciding  that  it  is  valid  and  should  be 
processed  by  the  IB. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>SD  Harbormaster  query  is  vaiid  destination  2</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy  Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>3/5/2009</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassif ier "  / > 

</scope> 

<oid>ruie2  8</oid> 

<!--SD  Harbormaster  query  is  vaiid  destination  2--> 

<if> 

<And> 

<And> 

<Equai> 

<ihs> 

<Atom> 

<Rei>User_Roie</Rei> 

<Var>Sub j  ect</Var> 

</Atom> 

</ihs> 

<rhs> 

<ind 
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type="string">"Harbormaster  San  Diego"</Ind> 
</ rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Destination_Port  Query"</Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"San  Diego "</Ind> 

</Atom> 

<Atom> 

<  Re 1 > V esse 1_C lassificatio n_L e ve 1 < / Re 1 > 

<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Destination_Port</Rel> 

<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 


Listing  39.  RuleML  code  for  RulelD  28 
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RulelD  29  is  titled  Alert  Oak  Secret  IB  2.  This  rule  is  established  as  a  trigger  within  the 
ruleset  to  identify  that  an  Alert  Message  is  present  and  to  verify  the  level  of  the  Alert 
Message  against  the  security  level  of  the  user  producing  the  query.  It  is  identical  in 
functionality  to  RulelD  26,  but  supports  the  generic  role  moniker  of  Harbormaster 
instead  of  Harbormaster  Oakland.  This  particular  rule  is  used  as  an  extension  to  our 
baseline  scenario  to  account  for  users  at  the  port  of  Oakland.  This  will  indicate  to  the  ID 
and  IB  that  an  alert  is  present  that  pertains  to  the  user  query,  and  that  the  user  is  below  the 
alert’s  classification  level. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Alert  Oak  Secret  IB  2</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 
<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 
</scope> 

<oid>rule2  9</oid> 

<! --Alert  Oak  Secret  IB  2--> 

<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 
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<Rel>Alert_Notif ication</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (SECRET  IB)  for  Port  of 

Oakland"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Oakland"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Sub j  ect</Var> 

<Ind 
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type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 

Listing  40.  RuleML  code  for  RulelD  29 

RulelD  30  is  titled  SD  Harbormaster  query  is  valid  origination.  This  rule  is  identical  in 
functionality  to  RulelD  32,  but  supports  the  extended  role  convention  using 
Harbormaster  San  Diego  instead  of  the  generic  Harbormaster  role.  This  rule  is  used  to 
verify  the  user  role  as  Harbormaster  San  Diego,  the  PDF  decision  is  TRUE,  and  the  type 
of  query  is  Originating_Port_Query  before  deciding  that  it  is  valid  and  should  be 
processed  by  the  IB.  This  rule  checks  the  query  that  is  being  processed  and  sets 
conditions  to  restrict  the  IB  response  as  a  result.  This  rule  is  designed  to  eliminate  the 
user’s  ability  to  repeatedly  query  the  system  to  troll  for  information,  or  the  lack  of 
information,  again  a  key  element  in  preventing  the  Misuse  Case.  In  the  original  system, 
queries  were  directly  processed  by  the  IB  after  entry.  In  the  re-architected  system,  we 
reroute  all  queries  through  the  ID  (per  Figure  26)  where  we  begin  the  new  data  flow  at 
continuation  point  I  instead  of  direct  processing  by  the  IB  in  the  original  flow.  In  this 
case,  the  query  and  resultant  data  must  include  the  Harbormaster’s  port  (either 
Origination  or  Destination)  for  details  to  be  returned  by  the  IB  and  ID.  This  is  part  of  the 
<Detect>  in  the  Security  Use  Case  that  we  had  to  reroute  queries  in  the  system.  This  will 
prevent  a  Harbormaster  from  continually  querying  the  system  to  get  information  about 
vessels  from  the  system  that  do  not  directly  pertain  to  his  or  her  role  (at  his  location)  and 
his  normal  performance  of  duty.  This  rule  verifies  that  the  user  is  a  Harbormaster  from 
San  Diego  and  conducting  an  Originating  Port  Query,  which  he  is  authorized  because  of 
his  role’s  duties  and  obligations,  as  well  as  a  PDF  service  check  to  validate  the  role’s 
permissions  to  execute  a  basic  query  and  to  access  information  from  the  IB.  The  rule  then 
establishes  this  as  a  valid  query  for  the  San  Diego  Harbormaster,  while  it  also  restricts  the 
query  response  by  limiting  Vessel_Classification_Level  to  the  User_Security_Level,  and 
setting  the  field  for  Vessel_Originating_Port  to  the  User_Role_Location,  or  in  this  case 
San  Diego. 
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<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>SD  Harbormaster  query  is  vaiid  origination</ind> 
</Fun> 

</Fxpr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy  Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>3/5/2009</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassif ier "  / > 

</scope> 

<oid>ruie30</ oid> 

<!--SD  Harbormaster  query  is  vaiid  origination--> 

<if> 

<And> 

<And> 

<Equai> 

<ihs> 

<Atom> 

<Rei>User_Roie</Rei> 

<Var>Sub j  ect</Var> 

</Atom> 

</ihs> 

<rhs> 

<ind 

type="string">"Harbormaster  San  Diego"</ind> 
</rhs> 

</Equai> 

<Equai> 

<ihs> 

<Atom> 

<Rei>HM_Queries</Rei> 

<Var>Sub j  ect</Var> 

</Atom> 

</ihs> 

<rhs> 

<ind 
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type="string">"Originating_Port  Query"</Ind> 
</ rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"San  Diego "</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif ication_Level</Rel> 

<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Originating_Port</Rel> 

<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 


Listing  41.  RuleML  code  for  RulelD  30 

RulelD  3 1  is  titled  Alert  Oak  TS  IB.  This  rule  is  established  as  a  trigger  within  the  ruleset 
to  identify  that  an  Alert  Message  is  present  and  to  verify  the  level  of  the  Alert  Message 
against  the  security  level  of  the  user  producing  the  query.  It  is  identical  in  functionality  to 
RulelD  33,  but  supports  the  generic  role  moniker  of  Harbormaster  instead  of 
Harbormaster  Oakland.  This  particular  rule  is  used  as  an  extension  to  our  baseline 
scenario  to  account  for  users  at  the  port  of  Oakland.  This  will  indicate  to  the  ID  and  IB 
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that  an  alert  is  present  that  pertains  to  the  user  query,  and  that  the  user  is  below  the  alert’s 
classifieation  level. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Alert  OakTS  IB</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 

</scope> 

<oid>rule31</oid> 

<! --Alert  OakTS  IB--> 

<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notif ication</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (TS  iB)  for  Port  of 

Oakland"</ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 
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<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top  Secret"</Ind> 
</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Oakland"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 


Listing  42.  RuleML  code  for  RulelD  3 1 


RulelD  32  is  titled  SD  Harbormaster  query  is  valid  origination  2.  This  rule  is  almost  a 

duplicate  of  RulelD  30,  but  is  used  to  support  an  alternative  method  of  designating  roles. 

In  this  case,  if  the  role  is  listed  as  the  generic  Harbormaster,  instead  of  the  Harbormaster 
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San  Diego  designation,  then  the  rule  will  process  similarly.  This  rule  checks  the  query 
that  is  being  processed  and  sets  conditions  to  restrict  the  IB  response  as  a  result.  This  rule 
is  designed  to  eliminate  the  user’s  ability  to  repeatedly  query  the  system  to  troll  for 
information,  or  the  lack  of  information,  again  a  key  element  in  preventing  the  Misuse 
Case.  In  the  original  system,  queries  were  directly  processed  by  the  IB  after  entry.  In  the 
re-architected  system,  we  reroute  all  queries  through  the  ID  (per  Figure  26)  where  we 
begin  the  new  data  flow  at  continuation  point  I  instead  of  direct  processing  by  the  IB  in 
the  original  flow.  In  this  case,  the  query  and  resultant  data  must  include  the 
Harbormaster’s  port  (either  Origination  or  Destination)  for  details  to  be  returned  by  the 
IB  and  ID.  This  is  part  of  the  <Detect>  in  the  Security  Use  Case  that  we  had  to  reroute 
queries  in  the  system.  This  will  prevent  a  Harbormaster  from  continually  querying  the 
system  to  get  information  about  vessels  from  the  system  that  do  not  directly  pertain  to  his 
or  her  role  (at  his  location)  and  his  normal  performance  of  duty.  This  rule  verifies  that  the 
user  is  a  Harbormaster  from  San  Diego  and  conducting  an  Originating  Port  Query,  which 
he  is  authorized  because  of  his  role’s  duties  and  obligations,  as  well  as  a  PDP  service 
check  to  validate  the  role’s  permissions  to  execute  a  basic  query  and  to  access 
information  from  the  IB.  The  rule  then  establishes  this  as  a  valid  query  for  the  San  Diego 
Harbormaster,  while  it  also  restricts  the  query  response  by  limiting 
Vessel_Classification_Level  to  the  User_Security_Level,  and  setting  the  field  for 
Vessel_Originating_Port  to  the  User_Role_Location,  or  in  this  case  San  Diego. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>SD  Harbormaster  query  is  vaiid  origination  2</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy  Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 
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<Fun 

uri="dc : date"> 

<Ind>3/5/200  9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 

</scope> 

<oid>rule32</oid> 

<!--SD  Harbormaster  query  is  valid  origination  2--> 

<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"San  Diego "</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Originating_Port  Query"</Ind> 
</rhs> 

</Equal> 

</And> 
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<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif ication_Level</Rel> 
<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Originating_Port</Rel> 
<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 


Listing  43.  RuleML  code  for  RulelD  32 


RulelD  33  is  titled  Alert  Oak  TS  IB  2.  This  rule  is  established  as  a  trigger  within  the 
ruleset  to  identify  that  an  Alert  Message  is  present  and  to  verify  the  level  of  the  Alert 
Message  against  the  security  level  of  the  user  producing  the  query.  This  rule  is  identical 
in  functionality  to  RulelD  30.  This  particular  rule  is  used  as  an  extension  to  our  baseline 
scenario  to  account  for  users  at  the  port  of  Oakland.  This  will  indicate  to  the  ID  and  IB 
that  an  alert  is  present  that  pertains  to  the  user  query,  and  that  the  user  is  below  the  alert’s 
classification  level. 


<Rule 

style=" active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 
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<Fun 

uri="dc : title"> 

<Ind>Alert  OakTS  IB  2</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 

</scope> 

<oid>rule33</oid> 

<! --Alert  OakTS  IB  2--> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Noti float ion</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (TS  IB)  for  Port  of 

Oakland"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top  Secret"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 
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<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster  Oakland"</Ind> 
</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 


Listing  44.  RuleML  code  for  RulelD  33 

RulelD  34  is  titled  IB  Results  0.1.  This  is  one  of  the  ten  IB  results  rules  that  is  intended  to 
replicate  the  results  from  an  actual  IB.  It  is  used,  based  on  the  variables  it  is  sourced  with 
to  provide  an  expected  result  when  testing  the  rule  base  with  a  sample  query.  In  this  case, 
it  returns  the  IB  result  of  “Vessel  Results  from  Unclassified  IB  with  ID  Injection  for 
Oakland  Alert.”  This  is  done  after  checking  the  user’s  security  level  and  for  the  presence 
of  an  alert  for  this  location.  The  IB,  in  this  case,  would  return  its  regular  result  from  the 
Unclassified  level  IB  (since  the  user  is  at  the  Unclassified  level),  and  then  the  required 
Alert  Message  insertion  from  the  higher  (TS  or  Secret)  IB.  The  level  of  the  Alert 
Message  is  not  revealed  to  the  user  from  the  IB.  This  rule  was  created  to  allow  for 
Harbormaster  queries  from  the  port  of  Oakland  as  an  extension  to  the  San  Diego  port 
accounted  for  in  our  scenario. 


<Rule 

style=" active" 

evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 


204 


<Ind>IB  Results  0.1</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 

</scope> 

<oid>rule34</oid> 

<! — IB  Results  0.1 — > 

<if> 

<And> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</Ind> 
</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Noti float ion</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 
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</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (SECRET  IB)  for  Port  of 

Oakland"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"Vessel  Results  from  Unclassified  IB  with  ID 
Injection  for  Oakland  Alert"</Ind> 

</Atom> 

</do> 

</Rule> 


Listing  45.  RuleML  code  for  RulelD  34 


RulelD  35  is  titled  IB  Results  0.2.  This  is  one  of  the  ten  IB  results  rules  that  is  intended  to 
replicate  the  results  from  an  actual  IB.  It  is  used,  based  on  the  variables  it  is  sourced  with 
to  provide  an  expected  result  when  testing  the  rule  base  with  a  sample  query.  In  this  case, 
it  returns  the  IB  result  of  “Vessel  Results  from  Unclassified  IB  with  ID  Injection  for  San 
Diego  Alert.”  This  is  done  after  checking  the  user’s  security  level  and  for  the  presence  of 
an  alert  for  this  location.  The  IB,  in  this  case,  would  return  its  regular  result  from  the 
Unclassified  level  IB  (since  the  user  is  at  the  Unclassified  level),  and  then  the  required 
Alert  Message  insertion  from  the  higher  (TS  or  Secret)  IB.  The  level  of  the  Alert 
Message  is  not  revealed  to  the  user  from  the  IB. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>IB  Results  0.2</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 
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<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 

</scope> 

<oid>rule35</ oid> 

<! — IB  Results  0.2 — > 

<if> 

<And> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notif ication</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (SECRET  IB)  for  Port  of  San 

Diego"</Ind> 

</rhs> 
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</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"Vessel  Results  from  Unclassified  IB  with  ID 
injection  for  San  Diego  Alert"</ind> 

</Atom> 

</do> 

</Rule> 


Listing  46.  RuleML  code  for  RulelD  35 


RulelD  36  is  titled  IB  Results  0.3.  This  is  one  of  the  ten  IB  results  rules  that  is  intended  to 
replicate  the  results  from  an  actual  IB.  It  is  used,  based  on  the  variables  it  is  sourced  with 
to  provide  an  expected  result  when  testing  the  rule  base  with  a  sample  query.  In  this  case, 
it  returns  the  IB  result  of  “Vessel  Results  from  Unclassified  IB  with  ID  Injection  for  San 
Diego  Alert.”  This  is  done  after  checking  the  user’s  security  level  and  for  the  presence  of 
an  alert  for  this  location.  The  IB,  in  this  case,  would  return  its  regular  result  from  the 
Unclassified  level  IB  (since  the  user  is  at  the  Unclassified  level),  and  then  the  required 
Alert  Message  insertion  from  the  TS  IB.  The  level  of  the  Alert  Message  is  not  revealed  to 
the  user  from  the  IB. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>IB  Results  0.3</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 
<Ind>Randy  Arvay</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 
<Ind>3/5/2009</Ind> 
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</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 

</scope> 

<oid>rule3  6</oid> 

Results  0.3--> 

<if> 

<And> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type=" s bring" >"Unclassified"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notif ication</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (TS  iB)  for  Port  of  San 

Diego"</ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_iB_Results</Rel> 

<Var>Sub j  ect</Var> 
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<Ind 

type="string">"Vessel  Results  from  Unclassified  IB  with  ID 
injection  for  San  Diego  Alert"</ind> 

</Atom> 

</do> 

</Rule> 


Listing  47.  RuleML  code  for  RulelD  36 


RulelD  37  is  titled  No  Alert  IB.  This  rule  is  established  as  a  trigger  within  the  ruleset  to 
identify  that  an  Alert  Message  is  not  present  at  a  higher  level  IB.  This  is  provide  a 
positive  response  to  a  negative  search  result  (i.e.,  no  alert  message  found). 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<ind>No  Alert  iB</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy  Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 
<ind>3/10/2009</ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<ind 

uri="#inf ormation_Declassif ier "  / > 
</scope> 

<oid>rule37</oid> 

<!--No  Alert  iB--> 

<if> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notif ication</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 
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<rhs> 

<Ind 

type="string">"No  Alert  Exists"</Ind> 
</rhs> 

</Equal> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</Rule> 


Listing  48.  RuleML  code  for  RulelD  37 


RulelD  38  is  titled  IB  Results  2.1.  This  is  one  of  the  ten  IB  results  rules  that  is  intended  to 
replicate  the  results  from  an  actual  IB.  It  is  used,  based  on  the  variables  it  is  sourced  with 
to  provide  an  expected  result  when  testing  the  rule  base  with  a  sample  query.  In  this  case, 
it  returns  the  IB  result  of  “Vessel  Results  from  Secret  IB  and  Unclassified  IB  with  ID 
Injection  for  San  Diego  Alert.”  This  is  done  after  checking  the  user’s  security  level  and 
for  the  presence  of  an  alert  for  this  location.  The  IB,  in  this  case,  would  return  its  regular 
result  from  both  the  Unclassified  and  Secret  level  IB’s  (since  the  user  is  at  the  Secret 
level),  and  then  the  required  Alert  Message  insertion  from  the  TS  IB. 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>IB  Results  2.1</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 
<Ind>Randy  Arvay</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 


211 


<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 

</scope> 

<oid>rule38</ oid> 

Results  2.1--> 

<if> 

<And> 

<And> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Secret"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notif ication</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (TS  IB)  for  Port  of  San 

Diego"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 
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<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"San  Diego"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"Vessel  Results  from  Secret  IB  and 
Unclassified  IB  with  ID  Injection  for  San  Diego  Alert"</Ind> 
</Atom> 

</do> 

</Rule> 


Listing  49.  RuleML  code  for  RulelD  38 


RulelD  39  is  titled  EWO  Query  is  Invalid.  This  is  a  filtering  rule  and  is  used  to  verify  that 
the  user  (EWO)  is  requesting  an  allowable  query.  It  verifies  the  role  of  the  query 
requestor  and  is  intended  to  provide  a  positive  response  to  the  query  check  in  the  case  of 
a  negative  response  (i.e.,  an  invalid  query  request). 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>EWO  query  is  invalid</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/10/2009</Ind> 

</Fun> 
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</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 

</scope> 

<oid>rule3  9</oid> 

<!--EWO  query  is  invalid--> 

<if> 

<0r> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Electronic  Warfare  Of f icer"</Ind> 
</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"EWO"</Ind> 

</rhs> 

</Equal> 

</0r> 

</if> 

<do> 

<Atom> 

<Rel>EWO_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</Rule> 


Listing  50.  RuleML  code  for  RulelD  39 


RulelD  40  is  titled  HM  Query  is  Invalid.  This  is  a  filtering  rule  and  is  used  to  verify  that 
the  user  (Harbormaster)  is  requesting  an  allowable  query.  In  this  case,  it  allows  for 
Harbormaster  queries  to  originate  from  San  Diego  and  Oakland  only.  Any  other  location 


214 


for  the  role  of  a  Harbormaster  will  make  the  query  invalid.  It  verifies  the  role  of  the  query 
requestor  and  is  intended  to  provide  a  positive  response  to  the  query  cheek  in  the  case  of 
a  negative  response  (i.e.,  an  invalid  query  request). 


<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>HM  query  is  invaiid</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy  Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>3/i0/2009</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassif ier "  /> 

</scope> 

<oid>ruie4  0</ oid> 

query  is  invaiid--> 

<if> 

<0r> 

<Equai> 

<ihs> 

<Atom> 

<Rei>User_Roie</Rei> 

<Var>Sub j  ect</Var> 

</Atom> 

</ihs> 

<rhs> 

<ind 

type="string">"Harbormaster  Oakiand"</ind> 
</rhs> 

</Equai> 

<Equai> 

<ihs> 

<Atom> 

<Rei>User  Roie</Rei> 
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<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster  San  Diego"</Ind> 
</rhs> 

</Equal> 

</0r> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</Rule> 

</Rulebase> 

</RuleML> 


Listing  5 1 .  RuleML  code  for  RulelD  40 
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APPENDIX  B.  RULEML  CODE 


<?xml  version="l . 0"  encoding="utf-8"?> 

<RuleML  xmlns="http : / / www . ruleml . org/ 0 . 91/xsd"> 

<Rulebase> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>MDA_Scenario_Arvay_current</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>12/4/2008</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<!--Rule  Policy  Inf ormation_Declassif ier--> 

<!--oid  of  the  rule  base  /  module  --> 

<Ind>Inf ormation_Declassif ier</ Ind> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Alert  Not  Valid  for  Role  Location</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/10/2009</Ind> 

</Fun> 

</Expr> 
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52 

53 

54 

55 

56 

57 

58 

59 

60 

61 

62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 

81 

82 

83 

84 

85 

86 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 

100 

101 

102 

103 

104 

105 

106 


</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 

</scope> 

<oid>rule0</ oid> 

<! --Alert  Not  Valid  for  Role  Location--> 

<if> 

<Or> 

<Or> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Noti float ion</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Alert  Exists  (SECRET  IB)  for  Port  of 

Los  Angeles"</lnd> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Noti float ion</Rel> 

<Var>Sub j  eot</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Alert  Exists  (TS  IB)  for  Port  of  Los 

Angeles "</lnd> 

</rhs> 

</Equal> 

</Or> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notif ioation</Rel> 

<Var>Sub j  eot</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"No  Alert  Exists"</lnd> 

</rhs> 

</Equal> 

</Or> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 
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107 

108 

109 

110 

111 

112 

113 

114 

115 

116 

117 

118 

119 

120 

121 

122 

123 

124 

125 

126 

127 

128 

129 

130 

131 

132 

133 

134 

135 

136 

137 

138 

139 

140 

141 

142 

143 

144 

145 

146 

147 

148 

149 

150 

151 

152 

153 

154 

155 

156 

157 

158 

159 

160 

161 


<Var>Sub j  ect</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>Alert  Notification  is  Present</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy  Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>2/26/2009</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassif ier "  /> 

</scope> 

<oid>ruiei</ oid> 

<!--Aiert  Notification  is  Present--> 

<if> 

<Equai> 

<ihs> 

<Atom> 

<Rei>Aiert_Present_Response</Rei> 
<Var>Sub j  ect</Var> 

</Atom> 

</ihs> 

<rhs> 

<ind 

type="booi">true</ind> 

</rhs> 

</Equai> 

</if> 

<do> 

<Atom> 

<Rei>Query_Requires_Data_insertion</Rei> 
<Var>Sub j  ect</Var> 


219 


162 

163 

164 

165 

166 

167 

168 

169 

170 

171 

172 

173 

174 

175 

176 

177 

178 

179 

180 

181 

182 

183 

184 

185 

186 

187 

188 

189 

190 

191 

192 

193 

194 

195 

196 

197 

198 

199 

200 

201 

202 

203 

204 

205 

206 

207 

208 

209 

210 

211 

212 

213 

214 

215 
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<Inci 

type="bool">true</Inci> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Est  Location  for  Role</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 
<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier"  /> 
</scope> 

<oid>rule2</oid> 

<!--Est  Location  for  Role--> 

<if> 

<Or> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Oakland"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Location</Rel> 

<Var>Sub j  ect</Var> 
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217 

218 

219 

220 

221 

222 

223 

224 

225 

226 

227 

228 

229 

230 

231 

232 

233 

234 

235 

236 

237 

238 

239 

240 

241 

242 

243 

244 

245 

246 

247 

248 

249 

250 

251 

252 

253 

254 

255 

256 

257 

258 

259 

260 

261 

262 

263 

264 

265 

266 

267 

268 

269 

270 

271 


</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"San  Diego"</Ind> 
</rhs> 

</Equal> 

</Or> 

</if> 

<do> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

<Atom> 

<Rel>Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>IB  Results  0</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

ur i="# Inf ormation_Declassi tier"  /> 
</scope> 

<oid>rule3</oid> 

<!--IB  Results  0--> 

<if> 

<And> 

<And> 

<And> 
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272 

273 

274 

275 

276 

277 

278 

279 

280 

281 

282 

283 

284 

285 

286 

287 

288 

289 

290 

291 

292 

293 

294 

295 

296 

297 

298 

299 

300 

301 

302 

303 

304 

305 

306 

307 

308 

309 

310 

311 

312 

313 

314 

315 

316 

317 

318 

319 

320 

321 

322 

323 

324 

325 

326 


<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notif ication</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (TS  IB)  for  Port  of 

Oakland"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"Vessel  Results  from  Unclassified  IB  with  ID 
Injection  for  Oakland  Alert"</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 
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327 

328 

329 

330 

331 

332 

333 

334 

335 

336 

337 

338 

339 

340 

341 

342 

343 

344 

345 

346 

347 

348 

349 

350 

351 

352 

353 

354 

355 

356 

357 

358 

359 

360 

361 

362 

363 

364 

365 

366 

367 

368 

369 

370 

371 

372 

373 

374 

375 

376 

377 

378 

379 

380 

381 


<Ind>Oakland  Harbormaster  query  is  valid 
destination</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 

</scope> 

<oid>rule4</oid> 

<! --Oakland  Harbormaster  query  is  valid  destination--> 
<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Oakland"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 
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382 

383 

384 

385 

386 

387 

388 

389 

390 

391 

392 

393 

394 

395 

396 

397 

398 

399 

400 

401 

402 

403 

404 

405 

406 

407 

408 

409 

410 

411 

412 

413 

414 

415 

416 

417 

418 

419 

420 

421 

422 

423 

424 

425 

426 

427 

428 

429 

430 

431 

432 

433 

434 

435 

436 


<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Destination_Port  Query"</Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif ication_Level</Rel> 

<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Destination_Port</Rel> 

<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>Policy  Decision  Point</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 
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437 

438 

439 

440 

441 

442 

443 

444 

445 

446 

447 

448 

449 

450 

451 

452 

453 

454 

455 

456 

457 

458 

459 

460 

461 

462 

463 

464 

465 

466 

467 

468 

469 

470 

471 

472 

473 

474 

475 

476 

477 

478 

479 

480 

481 

482 

483 

484 

485 

486 

487 

488 

489 

490 

491 


uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>2/26/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 

</scope> 

<oid>rule5</ oid> 

<! --Policy  Decision  Point--> 

<if> 

<Equal> 

<lhs> 

<Atom> 

<Re 1 >U  s  e  r_Ro 1 e_Pe  r mi ssions</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<ind 

type="bool">true</ind> 

</rhs> 

</Equal> 

</if> 

<do> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

<ind 

type="bool">true</ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<ind>Positive  ID  Response  to  iB  for  Alert</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 
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492 

493 

494 

495 

496 

497 

498 

499 

500 

501 

502 

503 

504 

505 

506 

507 

508 

509 
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513 

514 
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516 

517 

518 

519 

520 

521 

522 

523 

524 

525 

526 

527 

528 

529 

530 

531 

532 

533 

534 

535 

536 

537 

538 

539 

540 

541 

542 

543 

544 

545 

546 


<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>12/5/2008</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 

</scope> 

<oid>rule6</oid> 

<! --Positive  ID  Response  to  IB  for  AIert--> 
<if> 

<And> 

<Atom> 

<ReI>VaIid_Query</ReI> 

<Var>Sub j  ect</Var> 

</Atom> 

<Atom> 

<ReI>Query_Requires_Data_Insertion</ReI> 
<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<ReI>IB_Response_Wait</ReI> 

<Var>Sub j  ect</Var> 

<Ind 

type="booI">true</Ind> 

</Atom> 

</do> 

</RuIe> 

<RuIe 

style=" active" 
evaIuation="strong"> 

<IabeI> 

<PIex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Query  is  Valid</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 
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547 

548 

549 

550 

551 

552 

553 

554 

555 

556 

557 

558 

559 

560 

561 

562 

563 

564 

565 

566 

567 

568 

569 

570 

571 

572 

573 

574 

575 

576 

577 

578 

579 

580 

581 

582 

583 

584 

585 

586 

587 

588 

589 

590 

591 

592 

593 

594 

595 

596 

597 

598 

599 

600 

601 


<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/10/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 

</scope> 

<oid>rule7</oid> 

<! --Query  is  Valid--> 

<if> 

<Or> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

<Atom> 

<Rel>EWO_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Or> 

</if> 

<do> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Alert  Notification  is  Absent</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 
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602 

603 

604 

605 

606 

607 

608 

609 

610 

611 

612 

613 

614 

615 

616 

617 

618 

619 

620 

621 

622 

623 

624 

625 

626 

627 

628 

629 

630 

631 

632 

633 

634 

635 

636 

637 

638 

639 

640 

641 

642 

643 

644 

645 

646 

647 

648 

649 

650 

651 

652 

653 

654 

655 

656 


<Inci>2/2  6/200  9</Inci> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Inci 

uri="#Inf ormation_Declassif ier"  /> 
</scope> 

<oid>rule8</oid> 

<! --Alert  Notification  is  Absent — > 

<if> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">f alse</Ind> 

</rhs> 

</Equal> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Query_Requires_Data_Insertion</Rel> 
<Var>Sub j  ect</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Alert  SD  Secret  IB</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 
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657 

658 

659 

660 

661 

662 

663 

664 

665 

666 

667 

668 

669 

670 

671 

672 

673 

674 

675 

676 

677 

678 

679 

680 

681 

682 

683 

684 

685 

686 

687 

688 

689 

690 

691 

692 

693 

694 

695 

696 

697 

698 

699 

700 

701 

702 

703 

704 

705 

706 

707 

708 

709 

710 

711 


</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier"  /> 

</scope> 

<oid>rule9</oid> 

<! — Alert  SD  Secret  IB — > 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notif ication</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (SECRET  IB)  for  Port  of 

San  Diego"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster  San  Diego"</Ind> 
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712 

713 

714 

715 

716 

717 

718 

719 

720 

721 

722 

723 

724 

725 

726 

727 

728 

729 

730 

731 

732 

733 

734 

735 

736 

737 

738 

739 

740 

741 

742 

743 

744 

745 

746 

747 

748 

749 

750 

751 

752 

753 

754 

755 

756 

757 

758 

759 

760 

761 

762 

763 

764 

765 

766 


</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 
<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 


style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>EWO  query  is  valid</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 
<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier"  /> 
</scope> 

<oid>rulel0</ oid> 

<!--EWO  query  is  valid--> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 


230 


767 

768 

769 

770 

771 

772 

773 

llA 

775 

776 

777 

778 

779 

780 

781 

782 

783 

784 

785 

786 

787 

788 

789 

790 

791 

792 

793 

794 

795 

796 

797 

798 

799 

800 

801 

802 

803 

804 

805 

806 

807 

808 

809 

810 

811 

812 

813 

814 

815 

816 

817 

818 

819 

820 

821 


<Inci 

type="string">"EWO"</Inci> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top  Secret "</Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>EWO_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif ication_Level</Rel> 
<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>IB  Results  2</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 
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822 

823 

824 

825 

826 

827 

828 

829 

830 

831 

832 

833 

834 

835 

836 

837 

838 

839 

840 

841 

842 

843 

844 

845 

846 

847 

848 

849 

850 

851 

852 

853 

854 

855 

856 

857 

858 

859 

860 

861 

862 

863 

864 

865 

866 

867 

868 

869 

870 

871 

872 

873 

874 

875 

876 


</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier"  /> 

</scope> 

<oid>rulell</oid> 

<! — IB  Results  2 — > 

<if> 

<And> 

<And> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">" Secret "</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notif ication</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (TS  IB)  for  Port  of 

Oakland"</Ind> 

</rhs> 
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877 

878 

879 

880 

881 

882 

883 

884 

885 

886 

887 

888 

889 

890 

891 

892 

893 

894 

895 

896 

897 

898 

899 

900 

901 

902 

903 

904 

905 

906 

907 

908 

909 

910 

911 

912 

913 

914 

915 

916 

917 

918 

919 

920 

921 

922 

923 

924 

925 

926 

927 

928 

929 

930 

931 


</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Oakland"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"Vessel  Results  from  Secret  IB  and 
Unclassified  IB  with  ID  Injection  for  Oakland  Alert"</Ind> 
</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Negative  ID  Response  to  IB  for  Alert</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>2/26/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 

</scope> 
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932 

933 

934 

935 

936 

937 

938 

939 

940 

941 

942 

943 

944 

945 

946 

947 

948 

949 

950 

951 

952 

953 

954 

955 

956 

957 

958 

959 

960 

961 

962 

963 

964 

965 

966 

967 

968 

969 

970 

971 

972 

973 

974 

975 

976 

977 

978 

979 

980 

981 

982 

983 

984 

985 

986 


<oid>rulel2</ oid> 

<! --Negative  ID  Response  to  IB  for  AIert--> 

<if> 

<And> 

<Atom> 

<ReI>VaIid_Query</ReI> 

<Var>Sub j  ect</Var> 

</Atom> 

<EquaI> 

<Ihs> 

<Atom> 

<ReI>Query_Requires_Data_Insertion</ReI> 

<Var>Sub j  ect</Var> 

</Atom> 

</Ihs> 

<rhs> 

<Ind 

type="booI">f alse</lnd> 

</rhs> 

</EquaI> 

</And> 

</if> 

<do> 

<Atom> 

<ReI>IB_Response_Wait</ReI> 

<Var>Sub j  ect</Var> 

<Ind 

type="booI">f alse</lnd> 

</Atom> 

</do> 

</RuIe> 

<RuIe 

style=" active" 
evaIuation="strong"> 

<IabeI> 

<PIex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>OakIand  Harbormaster  query  is  valid  destination 

2</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 
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987 

988 

989 

990 

991 

992 

993 

994 

995 

996 

997 

998 

999 

1000 

1001 

1002 

1003 

1004 

1005 

1006 

1007 

1008 

1009 

1010 

1011 

1012 

1013 

1014 

1015 

1016 

1017 

1018 

1019 

1020 

1021 

1022 

1023 

1024 

1025 

1026 

1027 

1028 

1029 

1030 

1031 

1032 

1033 

1034 

1035 

1036 

1037 

1038 

1039 

1040 

1041 


</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 

</scope> 

<oid>rulel3</ oid> 

<! --Oakland  Harbormaster  query  is  valid  destination  2--> 
<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<ind 

type="string">"Harbormaster  Oakland"</ind> 
</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<ind 

type="string">"Destination_Port  Query"</ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<ind 

type="bool">true</ind> 

</Atom> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

<ind 

type="string">"Oakland"</ind> 

</Atom> 
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1042 

1043 

1044 

1045 

1046 

1047 

1048 

1049 

1050 

1051 

1052 

1053 

1054 

1055 

1056 

1057 

1058 

1059 

1060 

1061 

1062 

1063 

1064 

1065 

1066 

1067 

1068 

1069 

1070 

1071 

1072 

1073 

1074 

1075 

1076 

1077 

1078 

1079 

1080 

1081 

1082 

1083 

1084 

1085 

1086 

1087 

1088 

1089 

1090 

1091 

1092 

1093 

1094 

1095 

1096 


<Atom> 

<Rel>Vessel_Classif ication_Level</Rel> 
<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Destination_Port</Rel> 
<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>Policy  Decision  Point  2</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy  Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>2/2  6/2  0  0  9</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassif ier "  / > 
</scope> 

<oid>ruiei4</ oid> 

<!--Poiicy  Decision  Point  2--> 

<if> 

<Equai> 

<ihs> 

<Atom> 

<Rei>User_Roie_Permissions</Rei> 
<Var>Sub j  ect</Var> 
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1097 

1098 

1099 

1100 

1101 

1102 

1103 

1104 

1105 

1106 

1107 

1108 

1109 

1110 

nil 

1112 

1113 

1114 

1115 

1116 

1117 

1118 

1119 

1120 

1121 

1122 

1123 

1124 

1125 

1126 

1127 

1128 

1129 

1130 

1131 

1132 

1133 

1134 

1135 

1136 

1137 

1138 

1139 

1140 

1141 

1142 

1143 

1144 

1145 

1146 

1147 

1148 

1149 

1150 

1151 


</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">f alse</Ind> 

</rhs> 

</Equal> 

</if> 

<do> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>Query  Invalid</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 
<Ind>3/10/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 
</scope> 

<oid>rulel5</ oid> 

<! --Query  Invalid--> 

<if> 

<Or> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 
<Var>Sub j  ect</Var> 
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1152 

1153 

1154 

1155 

1156 

1157 

1158 

1159 

1160 

1161 

1162 

1163 

1164 

1165 

1166 

1167 

1168 

1169 

1170 

1171 

1172 

1173 

1174 

1175 

1176 

1177 

1178 

1179 

1180 

1181 

1182 

1183 

1184 

1185 

1186 

1187 

1188 

1189 

1190 

1191 

1192 

1193 

1194 

1195 

1196 

1197 

1198 

1199 

1200 

1201 

1202 

1203 

1204 

1205 

1206 


</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">true</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>EWO_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">true</Ind> 

</rhs> 

</Equal> 

</Or> 

</if> 

<do> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>Alert  SD  Secret  IB  2</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 
<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 
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1207 

1208 

1209 

1210 

1211 

1212 

1213 

1214 

1215 

1216 

1217 

1218 

1219 

1220 

1221 

1222 

1223 

1224 

1225 

1226 

1227 

1228 

1229 

1230 

1231 

1232 

1233 

1234 

1235 

1236 

1237 

1238 

1239 

1240 

1241 

1242 

1243 

1244 

1245 

1246 

1247 

1248 

1249 

1250 

1251 

1252 

1253 

1254 

1255 

1256 

1257 

1258 

1259 

1260 

1261 


<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 

</scope> 

<oid>rulel 6</oid> 

<! --Alert  SD  Secret  IB  2--> 

<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Noti float ion</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (SECRET  IB)  for  Port  of 

San  Diego"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type=" s bring" >"Unclassified"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 
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1262 

1263 

1264 

1265 

1266 

1267 

1268 

1269 

1270 

1271 

1272 

1273 

1274 

1275 

1276 

1277 

1278 

1279 

1280 

1281 

1282 

1283 

1284 

1285 

1286 

1287 

1288 

1289 

1290 

1291 

1292 

1293 

1294 

1295 

1296 

1297 

1298 

1299 

1300 

1301 

1302 

1303 

1304 

1305 

1306 

1307 

1308 

1309 

1310 

1311 

1312 

1313 

1314 

1315 

1316 


</lhs> 

<rhs> 

<Ind 

type="string">"San  Diego"</Ind> 
</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 
<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>IB  Results  3</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 
<Ind>2/26/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

ur i="# Inf ormation_Declassi tier"  /> 
</scope> 

<oid>rulel7</oid> 

<! — IB  Results  3 — > 

<if> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 
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1317 

1318 

1319 

1320 

1321 

1322 

1323 

1324 

1325 

1326 

1327 

1328 

1329 

1330 

1331 

1332 

1333 

1334 

1335 

1336 

1337 

1338 

1339 

1340 

1341 

1342 

1343 

1344 

1345 

1346 

1347 

1348 

1349 

1350 

1351 

1352 

1353 

1354 

1355 

1356 

1357 

1358 

1359 

1360 

1361 

1362 

1363 

1364 

1365 

1366 

1367 

1368 

1369 

1370 

1371 


<Equal> 

<lhs> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">f alse</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Secret"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"Vessel  Results  from  Secret  IB  and 
Unclassified  IB"</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Oakland  Harbormaster  query  is  valid 
origination</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 
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1372 

1373 

1374 

1375 

1376 

1377 

1378 

1379 

1380 

1381 

1382 

1383 

1384 

1385 

1386 

1387 

1388 

1389 

1390 

1391 

1392 

1393 

1394 

1395 

1396 

1397 

1398 

1399 

1400 

1401 

1402 

1403 

1404 

1405 

1406 

1407 

1408 

1409 

1410 

1411 

1412 

1413 

1414 

1415 

1416 

1417 

1418 

1419 

1420 

1421 

1422 

1423 

1424 

1425 

1426 


<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/200  9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 

</scope> 

<oid>rulel8</oid> 

<! --Oakland  Harbormaster  query  is  valid  origination--> 
<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Harbormaster  Oakland"</lnd> 
</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Originating_Port  Query"</lnd> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<lnd 

type="bool">true</lnd> 

</Atom> 
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1427 

1428 

1429 

1430 

1431 

1432 

1433 

1434 

1435 

1436 

1437 

1438 

1439 

1440 

1441 

1442 

1443 

1444 

1445 

1446 

1447 

1448 

1449 

1450 

1451 

1452 

1453 

1454 

1455 

1456 

1457 

1458 

1459 

1460 

1461 

1462 

1463 

1464 

1465 

1466 

1467 

1468 

1469 

1470 

1471 

1472 

1473 

1474 

1475 

1476 

1477 

1478 

1479 

1480 

1481 


<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"Oakland"</Ind> 

</Atom> 

<Atom> 

<  Re 1 > V esse 1_C lassificatio n_L e ve 1 < / Re 1 > 
<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Originating_Port</Rel> 
<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Alert  SD  TS  IB</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/200  9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 
</scope> 

<oid>rulel 9</oid> 

<! — Alert  SD  TS  IB — > 
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1482 

1483 

1484 

1485 

1486 

1487 

1488 

1489 

1490 

1491 

1492 

1493 

1494 

1495 

1496 

1497 

1498 

1499 

1500 

1501 

1502 

1503 

1504 

1505 

1506 

1507 

1508 

1509 

1510 

1511 

1512 

1513 

1514 

1515 

1516 

1517 

1518 

1519 

1520 

1521 

1522 

1523 

1524 

1525 

1526 

1527 

1528 

1529 

1530 

1531 

1532 

1533 

1534 

1535 

1536 


<if> 

<Anci> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notif ication</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Inci 

type="string">"Alert  Exists  (TS  IB)  for  Port  of  San 

Diego"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top  Secret"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster  San  Diego"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 
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1537 

1538 

1539 

1540 

1541 

1542 

1543 

1544 

1545 

1546 

1547 

1548 

1549 

1550 

1551 

1552 

1553 

1554 

1555 

1556 

1557 

1558 

1559 

1560 

1561 

1562 

1563 

1564 

1565 

1566 

1567 

1568 

1569 

1570 

1571 

1572 

1573 

1574 

1575 

1576 

1577 

1578 

1579 

1580 

1581 

1582 

1583 

1584 

1585 

1586 

1587 

1588 

1589 

1590 

1591 


<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Inci>EWO  query  is  valid  2</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier"  /> 

</scope> 

<oid>rule20</ oid> 

<!--EWO  query  is  valid  2--> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Electronic  Warfare  Of f icer"</Ind> 
</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top  Secret"</Ind> 

</rhs> 

</Equal> 
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1592 

1593 

1594 

1595 

1596 

1597 

1598 

1599 

1600 

1601 

1602 

1603 

1604 

1605 

1606 

1607 

1608 

1609 

1610 

1611 

1612 

1613 

1614 

1615 

1616 

1617 

1618 

1619 

1620 

1621 

1622 

1623 

1624 

1625 

1626 

1627 

1628 

1629 

1630 

1631 

1632 

1633 

1634 

1635 

1636 

1637 

1638 

1639 

1640 

1641 

1642 

1643 

1644 

1645 

1646 


</Anci> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Anci> 

</if> 

<do> 

<Atom> 

<Rel>EWO_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif ication_Level</Rel> 
<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>IB  Results  4</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>2/26/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

ur i="# Inf ormation_Declassi tier"  /> 
</scope> 

<oid>rule21</oid> 

<!--IB  Results  4--> 
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1647 

1648 

1649 

1650 

1651 

1652 

1653 

1654 

1655 

1656 

1657 

1658 

1659 

1660 

1661 

1662 

1663 

1664 

1665 

1666 

1667 

1668 

1669 

1670 

1671 

1672 

1673 

1674 

1675 

1676 

1677 

1678 

1679 

1680 

1681 

1682 

1683 

1684 

1685 

1686 

1687 

1688 

1689 

1690 

1691 

1692 

1693 

1694 

1695 

1696 

1697 

1698 

1699 

1700 

1701 


<if> 

<Anci> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

<Equal> 

<lhs> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">f alse</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"Vessel  Results  from  Unclassified  IB"</Ind> 
</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Oakland  Harbormaster  query  is  valid  origination 

2</Ind> 

</Fun> 

</Expr> 
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1702 

1703 

1704 

1705 

1706 

1707 

1708 

1709 

1710 

1711 

1712 

1713 

1714 

1715 

1716 

1717 

1718 

1719 

1720 

1721 

1722 

1723 

1724 

1725 

1726 

1727 

1728 

1729 

1730 

1731 

1732 

1733 

1734 

1735 

1736 

1737 

1738 

1739 

1740 

1741 

1742 

1743 

1744 

1745 

1746 

1747 

1748 

1749 

1750 

1751 

1752 

1753 

1754 

1755 

1756 


<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/200  9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 

</scope> 

<oid>rule22</oid> 

<! --Oakland  Harbormaster  query  is  valid  origination  2--> 
<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<ind 

type="string">"Harbormaster"</ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<ind 

type="string">"Oakland"</ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 
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1757 

1758 

1759 

1760 

1761 

1762 

1763 

1764 

1765 

1766 

1767 

1768 

1769 

1770 

1771 

1772 

1773 

1774 

1775 

1776 

1777 

1778 

1779 

1780 

1781 

1782 

1783 

1784 

1785 

1786 

1787 

1788 

1789 

1790 

1791 

1792 

1793 

1794 

1795 

1796 

1797 

1798 

1799 

1800 

1801 

1802 

1803 

1804 

1805 

1806 

1807 

1808 

1809 

1810 

1811 


</lhs> 

<rhs> 

<Ind 

type="string">"Originating_Port  Query"</Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif ication_Level</Rel> 

<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Originating_Port</Rel> 

<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Alert  SD  TS  IB  2</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 
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1812 

1813 

1814 

1815 

1816 

1817 

1818 

1819 

1820 

1821 

1822 

1823 

1824 

1825 

1826 

1827 

1828 

1829 

1830 

1831 

1832 

1833 

1834 

1835 

1836 

1837 

1838 

1839 

1840 

1841 

1842 

1843 

1844 

1845 

1846 

1847 

1848 

1849 

1850 

1851 

1852 

1853 

1854 

1855 

1856 

1857 

1858 

1859 

1860 

1861 

1862 

1863 

1864 

1865 

1866 


<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/200  9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 

</scope> 

<oid>rule23</oid> 

<! — Alert  SD  TS  IB  2 — > 

<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Noti float ion</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (TS  IB)  for  Port  of  San 

Diego"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top  Secret"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster"</Ind> 

</rhs> 
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1867 

1868 

1869 

1870 

1871 

1872 

1873 

1874 

1875 

1876 

1877 

1878 

1879 

1880 

1881 

1882 

1883 

1884 

1885 

1886 

1887 

1888 

1889 

1890 

1891 

1892 

1893 

1894 

1895 

1896 

1897 

1898 

1899 

1900 

1901 

1902 

1903 

1904 

1905 

1906 

1907 

1908 

1909 

1910 

1911 

1912 

1913 

1914 

1915 

1916 

1917 

1918 

1919 

1920 

1921 


</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"San  Diego"</Ind> 
</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 
<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>IB  Results  5</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 
</scope> 

<oid>rule2  4</oid> 
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1922 

1923 

1924 

1925 

1926 

1927 

1928 

1929 

1930 

1931 

1932 

1933 

1934 

1935 

1936 

1937 

1938 

1939 

1940 

1941 

1942 

1943 

1944 

1945 

1946 

1947 

1948 

1949 

1950 

1951 

1952 

1953 

1954 

1955 

1956 

1957 

1958 

1959 

1960 

1961 

1962 

1963 

1964 

1965 

1966 

1967 

1968 

1969 

1970 

1971 

1972 

1973 

1974 

1975 

1976 


Results  5--> 

<if> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

<Equal> 

<lhs> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="bool">f alse</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top  Secret"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"Vessel  Results  from  TS  IB,  Secret  IB,  and 
Unclassified  1B"</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<lnd>SD  Harbormaster  query  is  valid  destination</ind> 
</Fun> 
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1977 

1978 

1979 

1980 

1981 

1982 

1983 

1984 

1985 

1986 

1987 

1988 

1989 

1990 

1991 

1992 

1993 

1994 

1995 

1996 

1997 

1998 

1999 

2000 

2001 

2002 

2003 

2004 

2005 

2006 

2007 

2008 

2009 

2010 

2011 

2012 

2013 

2014 

2015 

2016 

2017 

2018 

2019 

2020 

2021 

2022 

2023 

2024 

2025 

2026 

2027 

2028 

2029 

2030 

2031 


</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 

</scope> 

<oid>rule25</oid> 

<!--SD  Harbormaster  query  is  valid  destination--> 
<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type=" s bring" >"Harbormaster"</Ind> 
</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"San  Diego"</Ind> 
</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Sub j  ect</Var> 
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2032 

2033 

2034 

2035 

2036 

2037 

2038 

2039 

2040 

2041 

2042 

2043 

2044 

2045 

2046 

2047 

2048 

2049 

2050 

2051 

2052 

2053 

2054 

2055 

2056 

2057 

2058 

2059 

2060 

2061 

2062 

2063 

2064 

2065 

2066 

2067 

2068 

2069 

2070 

2071 

2072 

2073 

2074 

2075 

2076 

2077 

2078 

2079 

2080 

2081 

2082 

2083 

2084 

2085 

2086 


</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Destination_Port  Query"</Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<  Re 1 > V esse 1_C lassificatio n_L e ve 1 < / Re 1 > 

<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Destination_Port</Rel> 

<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Alert  Oak  Secret  IB</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 
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2087 

2088 

2089 

2090 

2091 

2092 

2093 

2094 

2095 

2096 

2097 

2098 

2099 

2100 

2101 

2102 

2103 

2104 

2105 

2106 

2107 

2108 

2109 

2110 

2111 

2112 

2113 

2114 

2115 

2116 

2117 

2118 

2119 

2120 

2121 

2122 

2123 

2124 

2125 

2126 

2127 

2128 

2129 

2130 

2131 

2132 

2133 

2134 

2135 

2136 

2137 

2138 

2139 

2140 

2141 


</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/200  9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 

</scope> 

<oid>rule2  6</oid> 

<! --Alert  Oak  Secret  IB--> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Noti float ion</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Alert  Exists  (SECRET  IB)  for  Port  of 

Oakland"</lnd> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Unclassif ied"</lnd> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Harbormaster  Oakland"</lnd> 

</rhs> 
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2142 

2143 

2144 

2145 

2146 

2147 

2148 

2149 

2150 

2151 

2152 

2153 

2154 

2155 

2156 

2157 

2158 

2159 

2160 

2161 

2162 

2163 

2164 

2165 

2166 

2167 

2168 

2169 

2170 

2171 

2172 

2173 

2174 

2175 

2176 

2177 

2178 

2179 

2180 

2181 

2182 

2183 

2184 

2185 

2186 

2187 

2188 

2189 

2190 

2191 

2192 

2193 

2194 

2195 

2196 


</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 
<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>IB  Results  6</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 
<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 
</scope> 

<oid>rule27</oid> 

Results  6--> 

<if> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="bool">f alse</lnd> 

</rhs> 
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2197 

2198 

2199 

2200 

2201 

2202 

2203 

2204 

2205 

2206 

2207 

2208 

2209 

2210 

2211 

2212 

2213 

2214 

2215 

2216 

2217 

2218 

2219 

2220 

2221 

2222 

2223 

2224 

2225 

2226 

2227 

2228 

2229 

2230 

2231 

2232 

2233 

2234 

2235 

2236 

2237 

2238 

2239 

2240 

2241 

2242 

2243 

2244 

2245 

2246 

2247 

2248 

2249 

2250 

2251 


</Equal> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"Invalid  Query! "</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>SD  Harbormaster  query  is  vaiid  destination  2</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy  Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>3/5/2009</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassif ier "  /> 

</scope> 

<oid>ruie2  8</ oid> 

<!--SD  Harbormaster  query  is  vaiid  destination  2--> 

<if> 

<And> 

<And> 

<Equai> 

<ihs> 

<Atom> 

<Rei>User_Roie</Rei> 

<Var>Sub j  ect</Var> 

</Atom> 

</ihs> 

<rhs> 

<ind 

type="string">"Harbormaster  San  Diego"</ind> 
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2252 

2253 

2254 

2255 

2256 

2257 

2258 

2259 

2260 

2261 

2262 

2263 

2264 

2265 

2266 

2267 

2268 

2269 

2270 

2271 

2272 

2273 

2274 

2275 

2276 

2277 

2278 

2279 

2280 

2281 

2282 

2283 

2284 

2285 

2286 

2287 

2288 

2289 

2290 

2291 

2292 

2293 

2294 

2295 

2296 

2297 

2298 

2299 

2300 

2301 

2302 

2303 

2304 

2305 

2306 


</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Inci 

type="string">"Destination_Port  Query"</Inci> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"San  Diego"</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif ication_Level</Rel> 

<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Destination_Port</Rel> 

<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 
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2307 

2308 

2309 

2310 

2311 

2312 

2313 

2314 

2315 

2316 

2317 

2318 

2319 

2320 

2321 

2322 

2323 

2324 

2325 

2326 

2327 

2328 

2329 

2330 

2331 

2332 

2333 

2334 

2335 

2336 

2337 

2338 

2339 

2340 

2341 

2342 

2343 

2344 

2345 

2346 

2347 

2348 

2349 

2350 

2351 

2352 

2353 

2354 

2355 

2356 

2357 

2358 

2359 

2360 

2361 


<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Inci>Alert  Oak  Secret  IB  2</Inci> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="cic :  author"> 

<Inci>Ranciy  Arvay</Inci> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="cic :  ciate"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

ur i="# Inf ormation_Declassi tier"  /> 

</scope> 

<oid>rule2  9</oid> 

<! --Alert  Oak  Secret  IB  2--> 

<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notif ication</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (SECRET  IB)  for  Port  of 

Oakland"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</Ind> 


259 


2362 

2363 

2364 

2365 

2366 

2367 

2368 

2369 

2370 

2371 

2372 

2373 

2374 

2375 

2376 

2377 

2378 

2379 

2380 

2381 

2382 

2383 

2384 

2385 

2386 

2387 

2388 

2389 

2390 

2391 

2392 

2393 

2394 

2395 

2396 

2397 

2398 

2399 

2400 

2401 

2402 

2403 

2404 

2405 

2406 

2407 

2408 

2409 

2410 

2411 

2412 

2413 

2414 

2415 

2416 


</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Inci 

type="string">"Harbormaster"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Oakland"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>SD  Harbormaster  query  is  vaiid  origination</Ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 
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2417 

2418 

2419 

2420 

2421 

2422 

2423 

2424 

2425 

2426 

2427 

2428 

2429 

2430 

2431 

2432 

2433 

2434 

2435 

2436 

2437 

2438 

2439 

2440 

2441 

2442 

2443 

2444 

2445 

2446 

2447 

2448 

2449 

2450 

2451 

2452 

2453 

2454 

2455 

2456 

2457 

2458 

2459 

2460 

2461 

2462 

2463 

2464 

2465 

2466 

2467 

2468 

2469 

2470 

2471 


</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/200  9</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 

</scope> 

<oid>rule30</oid> 

<!--SD  Harbormaster  query  is  valid  origination--> 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster  San  Diego"</Ind> 
</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="s bring" >" Or iginating_Port  Query"</Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 
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2472 

2473 

2474 

2475 

2476 

2477 

2478 

2479 

2480 

2481 

2482 

2483 

2484 

2485 

2486 

2487 

2488 

2489 

2490 

2491 

2492 

2493 

2494 

2495 

2496 

2497 

2498 

2499 

2500 

2501 

2502 

2503 

2504 

2505 

2506 

2507 

2508 

2509 

2510 

2511 

2512 

2513 

2514 

2515 

2516 

2517 

2518 

2519 

2520 

2521 

2522 

2523 

2524 

2525 

2526 


</Atom> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"San  Diego"</Ind> 
</Atom> 

<Atom> 

<  Re 1 > V esse 1_C lassificatio n_L e ve 1 < / Re 1 > 
<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Originating_Port</Rel> 
<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Role_Location</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Alert  OakTS  IB</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  / > 
</scope> 

<oid>rule31</oid> 
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2527 

2528 

2529 

2530 

2531 

2532 

2533 

2534 

2535 

2536 

2537 

2538 

2539 

2540 

2541 

2542 

2543 

2544 

2545 

2546 

2547 

2548 

2549 

2550 

2551 

2552 

2553 

2554 

2555 

2556 

2557 

2558 

2559 

2560 

2561 

2562 

2563 

2564 

2565 

2566 

2567 

2568 

2569 

2570 

2571 

2572 

2573 

2574 

2575 

2576 

2577 

2578 

2579 

2580 

2581 


<! --Alert  OakTS  IB--> 

<if> 

<And> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Noti float ion</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Alert  Exists  (TS  IB)  for  Port  of 

Oakland"</lnd> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Top  Secret"</lnd> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Harbormaster"</lnd> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<lnd 

type="string">"Oakland"</lnd> 

</rhs> 
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2582 

2583 

2584 

2585 

2586 

2587 

2588 

2589 

2590 

2591 

2592 

2593 

2594 

2595 

2596 

2597 

2598 

2599 

2600 

2601 

2602 

2603 

2604 

2605 

2606 

2607 

2608 

2609 

2610 

2611 

2612 

2613 

2614 

2615 

2616 

2617 

2618 

2619 

2620 

2621 

2622 

2623 

2624 

2625 

2626 

2627 

2628 

2629 

2630 

2631 

2632 

2633 

2634 

2635 

2636 


</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>SD  Harbormaster  query  is  vaiid  origination  2</ind> 
</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy  Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>3/5/2009</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassif ier "  /> 

</scope> 

<oid>ruie32</ oid> 

<!--SD  Harbormaster  query  is  vaiid  origination  2--> 

<if> 

<And> 

<And> 

<And> 

<Equai> 

<ihs> 

<Atom> 

<Rei>User_Roie</Rei> 

<Var>Sub j  ect</Var> 

</Atom> 

</ihs> 

<rhs> 


264 


2637 

2638 

2639 

2640 

2641 

2642 

2643 

2644 

2645 

2646 

2647 

2648 

2649 

2650 

2651 

2652 

2653 

2654 

2655 

2656 

2657 

2658 

2659 

2660 

2661 

2662 

2663 

2664 

2665 

2666 

2667 

2668 

2669 

2670 

2671 

2672 

2673 

2674 

2675 

2676 

2677 

2678 

2679 

2680 

2681 

2682 

2683 

2684 

2685 

2686 

2687 

2688 

2689 

2690 

2691 


<Inci 

type="string">"Harbormaster"</Inci> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"San  Diego"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>HM_Queries</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Originating_Port  Query"</Ind> 
</rhs> 

</Equal> 

</And> 

<Atom> 

<Rel>PDP_Decision</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

<Atom> 

<Rel>Vessel_Classif ication_Level</Rel> 

<Var>Sub j  ect</Var> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

<Atom> 

<Rel>Vessel_Originating_Port</Rel> 

<Var>Sub j  ect</Var> 

<Atom> 


265 


2692 

2693 

2694 

2695 

2696 

2697 

2698 

2699 

2700 

2701 

2702 

2703 

2704 

2705 

2706 

2707 

2708 

2709 

2710 

2711 

2712 

2713 

2714 

2715 

2716 

2717 

2718 

2719 

2720 

2721 

2722 

2723 

2724 

2725 

2726 

2727 

2728 

2729 

2730 

2731 

2732 

2733 

2734 

2735 

2736 

2737 

2738 

2739 

2740 

2741 

2742 

2743 

2744 

2745 

2746 


<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>Alert  OakTS  IB  2</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

ur i="# Inf ormation_Declassi tier"  /> 

</scope> 

<oid>rule33</ oid> 

<! — Alert  OakTS  IB  2 — > 

<if> 

<And> 

<And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notif ication</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (TS  IB)  for  Port  of 

Oakland"</Ind> 

</rhs> 

</Equal> 

<Equal> 

<lhs> 
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2747 

2748 

2749 

2750 

2751 

2752 

2753 

2754 

2755 

2756 

2757 

2758 

2759 

2760 

2761 

2762 

2763 

2764 

2765 

2766 

2767 

2768 

2769 

2770 

2771 

2772 

2773 

2774 

2775 

2776 

2777 

2778 

2779 

2780 

2781 

2782 

2783 

2784 

2785 

2786 

2787 

2788 

2789 

2790 

2791 

2792 

2793 

2794 

2795 

2796 

2797 

2798 

2799 

2800 

2801 


<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Top  Secret"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Harbormaster  Oakland"</Ind> 
</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">true</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : 

<Ind>IB  Results  0.1</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/200  9</Ind> 


267 


2802 

2803 

2804 

2805 

2806 

2807 

2808 

2809 

2810 

2811 

2812 

2813 

2814 

2815 

2816 

2817 

2818 

2819 

2820 

2821 

2822 

2823 

2824 

2825 

2826 

2827 

2828 

2829 

2830 

2831 

2832 

2833 

2834 

2835 

2836 

2837 

2838 

2839 

2840 

2841 

2842 

2843 

2844 

2845 

2846 

2847 

2848 

2849 

2850 

2851 

2852 

2853 

2854 

2855 

2856 


</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Inci 

uri="#Inf ormation_Declassif ier"  /> 

</scope> 

<oid>rule34</oid> 

<! — IB  Results  0.1 — > 

<if> 

<And> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notif ication</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (SECRET  IB)  for  Port  of 

Oakland"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Sub j  ect</Var> 
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2857 

2858 

2859 

2860 

2861 

2862 

2863 

2864 

2865 

2866 

2867 

2868 

2869 

2870 

2871 

2872 

2873 

2874 

2875 

2876 

2877 

2878 

2879 

2880 

2881 

2882 

2883 

2884 

2885 

2886 

2887 

2888 

2889 

2890 

2891 

2892 

2893 

2894 

2895 

2896 

2897 

2898 

2899 

2900 

2901 

2902 

2903 

2904 

2905 

2906 

2907 

2908 

2909 

2910 

2911 


<Inci 

type="string">"Vessel  Results  from  Unclassified  IB  with  ID 
Injection  for  Oakland  Alert"</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>IB  Results  0.2</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier"  /> 

</scope> 

<oid>rule35</ oid> 

<! — IB  Results  0.2 — > 

<if> 

<And> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 
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2912 

2913 

2914 

2915 

2916 

2917 

2918 

2919 

2920 

2921 

2922 

2923 

2924 

2925 

2926 

2927 

2928 

2929 

2930 

2931 

2932 

2933 

2934 

2935 

2936 

2937 

2938 

2939 

2940 

2941 

2942 

2943 

2944 

2945 

2946 

2947 

2948 

2949 

2950 

2951 

2952 

2953 

2954 

2955 

2956 

2957 

2958 

2959 

2960 

2961 

2962 

2963 

2964 

2965 

2966 


</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notif ication</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (SECRET  IB)  for  Port  of  San 

Diego"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"Vessel  Results  from  Unclassified  IB  with  ID 
Injection  for  San  Diego  Alert"</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>IB  Results  0.3</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/200  9</Ind> 

</Fun> 
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2967 

2968 

2969 

2970 

2971 

2972 

2973 

2974 

2975 

2976 

2977 

2978 

2979 

2980 

2981 

2982 

2983 

2984 

2985 

2986 

2987 

2988 

2989 

2990 

2991 

2992 

2993 

2994 

2995 

2996 

2997 

2998 

2999 

3000 

3001 

3002 

3003 

3004 

3005 

3006 

3007 

3008 

3009 

3010 

3011 

3012 

3013 

3014 

3015 

3016 

3017 

3018 

3019 

3020 

3021 


</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier"  /> 

</scope> 

<oid>rule3  6</oid> 

<! — IB  Results  0.3  —  > 

<if> 

<And> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Unclassif ied"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Noti float ion</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (TS  IB)  for  Port  of  San 

Diego"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Sub j  ect</Var> 

<Ind 
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3022 

3023 

3024 

3025 

3026 

3027 

3028 

3029 

3030 

3031 

3032 

3033 

3034 

3035 

3036 

3037 

3038 

3039 

3040 

3041 

3042 

3043 

3044 

3045 

3046 

3047 

3048 

3049 

3050 

3051 

3052 

3053 

3054 

3055 

3056 

3057 

3058 

3059 

3060 

3061 

3062 

3063 

3064 

3065 

3066 

3067 

3068 

3069 

3070 

3071 

3072 

3073 

3074 

3075 

3076 


type="string">"Vessel  Results  from  Unclassified  IB  with  ID 
injection  for  San  Diego  Alert"</ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<ind>No  Alert  iB</ind> 

</Fun> 

</Fxpr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy  Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>3/10/2009</ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<ind 

uri="#inf ormation_Declassif ier "  /> 

</scope> 

<oid>rule37</oid> 

<!--No  Alert  iB--> 

<if> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Noti float ion</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<ind 

type="string">"No  Alert  Exists"</ind> 

</rhs> 

</Equal> 

</if> 

<do> 

<Atom> 

<Rel>Alert_Present_Response</Rel> 

<Var>Sub j  ect</Var> 

<ind 
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3077 

3078 

3079 

3080 

3081 

3082 

3083 

3084 

3085 

3086 

3087 

3088 

3089 

3090 

3091 

3092 

3093 

3094 

3095 

3096 

3097 

3098 

3099 

3100 

3101 

3102 

3103 

3104 

3105 

3106 

3107 

3108 

3109 

3110 

3111 

3112 

3113 

3114 

3115 

3116 

3117 

3118 

3119 

3120 

3121 

3122 

3123 

3124 

3125 

3126 

3127 

3128 

3129 

3130 

3131 


type="bool">f  alse</Inci> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="cic :  title"> 

<Ind>IB  Results  2.1</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/5/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

ur i="# Inf ormation_Declassi tier"  /> 
</scope> 

<oid>rule38</oid> 

<! — IB  Results  2.1 — > 

<if> 

<And> 

<And> 

<And> 

<And> 

<Atom> 

<Rel>Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

<Atom> 

<Rel>IB_Response_Wait</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Security_Level</Rel> 
<Var>Sub j  ect</Var> 

</Atom> 
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3132 

3133 

3134 

3135 

3136 

3137 

3138 

3139 

3140 

3141 

3142 

3143 

3144 

3145 

3146 

3147 

3148 

3149 

3150 

3151 

3152 

3153 

3154 

3155 

3156 

3157 

3158 

3159 

3160 

3161 

3162 

3163 

3164 

3165 

3166 

3167 

3168 

3169 

3170 

3171 

3172 

3173 

3174 

3175 

3176 

3177 

3178 

3179 

3180 

3181 

3182 

3183 

3184 

3185 

3186 


</lhs> 

<rhs> 

<Ind 

type="string">" Secret "</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>Alert_Notif ication</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Alert  Exists  (TS  IB)  for  Port  of  San 

Diego"</Ind> 

</rhs> 

</Equal> 

</And> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role_Location</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"San  Diego"</Ind> 

</rhs> 

</Equal> 

</And> 

</if> 

<do> 

<Atom> 

<Rel>Return_IB_Results</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="string">"Vessel  Results  from  Secret  IB  and 
Unclassified  IB  with  ID  Injection  for  San  Diego  Alert"</Ind> 

</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>EWO  query  is  invalid</Ind> 

</Fun> 
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3187 

3188 

3189 

3190 

3191 

3192 

3193 

3194 

3195 

3196 

3197 

3198 

3199 

3200 

3201 

3202 

3203 

3204 

3205 

3206 

3207 

3208 

3209 

3210 

3211 

3212 

3213 

3214 

3215 

3216 

3217 

3218 

3219 

3220 

3221 

3222 

3223 

3224 

3225 

3226 

3227 

3228 

3229 

3230 

3231 

3232 

3233 

3234 

3235 

3236 

3237 

3238 

3239 

3240 

3241 


</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<Ind>Randy  Arvay</Ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<Ind>3/10/2009</Ind> 

</Fun> 

</Expr> 

</Plex> 

</label> 

<scope> 

<Ind 

uri="#Inf ormation_Declassif ier "  /> 

</scope> 

<oid>rule3  9</oid> 

<!--EWO  query  is  invalid--> 

<if> 

<Or> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"Electronic  Warfare  Of f icer"</Ind> 
</rhs> 

</Equal> 

<Equal> 

<lhs> 

<Atom> 

<Rel>User_Role</Rel> 

<Var>Sub j  ect</Var> 

</Atom> 

</lhs> 

<rhs> 

<Ind 

type="string">"EWO"</Ind> 

</rhs> 

</Equal> 

</Or> 

</if> 

<do> 

<Atom> 

<Rel>EWO_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">f alse</Ind> 
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3242 

3243 

3244 

3245 

3246 

3247 

3248 

3249 

3250 

3251 

3252 

3253 

3254 

3255 

3256 

3257 

3258 

3259 

3260 

3261 

3262 

3263 

3264 

3265 

3266 

3267 

3268 

3269 

3270 

3271 

3272 

3273 

3274 

3275 

3276 

3277 

3278 

3279 

3280 

3281 

3282 

3283 

3284 

3285 

3286 

3287 

3288 

3289 

3290 

3291 

3292 

3293 

3294 

3295 

3296 


</Atom> 

</do> 

</Rule> 

<Rule 

style=" active" 
evaluation="strong"> 

<label> 

<Plex> 

<Expr> 

<Fun 

uri="dc : title"> 

<Ind>HM  query  is  invaiid</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : author"> 

<ind>Randy  Arvay</ind> 

</Fun> 

</Expr> 

<Expr> 

<Fun 

uri="dc : date"> 

<ind>3/i0/2009</ind> 

</Fun> 

</Expr> 

</Piex> 

</iabei> 

<scope> 

<ind 

uri="#inf ormation_Deciassif ier "  / > 

</scope> 

<oid>ruie4  0</oid> 

query  is  invaiid--> 

<if> 

<Or> 

<Equai> 

<ihs> 

<Atom> 

<Rei>User_Roie</Rei> 

<Var>Sub j  ect</Var> 

</Atom> 

</ihs> 

<rhs> 

<ind 

type="string">"Harbormaster  Oakiand"</ind> 
</rhs> 

</Equai> 

<Equai> 

<ihs> 

<Atom> 

<Rei>User_Roie</Rei> 

<Var>Sub j  ect</Var> 

</Atom> 

</ihs> 
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3297 

3298 

3299 

3300 

3301 

3302 

3303 

3304 

3305 

3306 

3307 

3308 

3309 

3310 

3311 

3312 

3313 

3314 


<rhs> 

<Ind 

type="string">"Harbormaster  San  Diego"</Ind> 
</rhs> 

</Equal> 

</Or> 

</if> 

<do> 

<Atom> 

<Rel>HM_Valid_Query</Rel> 

<Var>Sub j  ect</Var> 

<Ind 

type="bool">f alse</Ind> 

</Atom> 

</do> 

</Rule> 

</Rulebase> 

</RuleML> 
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APPENDIX  C.  RULE  TRACE  OF  USE  CASE  SUPPORTED 


The  visual  trace  of  the  ruleset  execution  to  show  support  for  the  system’s  intended 

use.  This  trace  is  completed  using  the  following  parameters: 

Type  of  query:  Destination  Port 

Role  /  Actor:  Harbormaster 

Location:  San  Diego 

Security  Level:  Unclassified 

Alert  Present:  False 

Alert  Classification  Level:  Not  Applicable 

Expected  Result:  “Vessel  Results  from  Unclassified  IB’’ 


The  expected  result  from  this  query  and  the  RuleML  execution  is  an  IB  response  of 
“Vessel  Results  from  Unclassified  IB’’  to  the  user.  The  trace  was  completed  using 
RuIeManager’s  Interactive  Rule  Map  functionality.  The  pop-up  boxes  shown  throughout 
the  trace  indicate  the  sourcing  of  predicates  that  would  be  included  with  tagged  data  in  a 
live  system.  This  was  not  replicated  for  this  research  and  instead  was  manually  inserted 
via  the  dialog  boxes. 

For  the  rule  trace  shown  and  from  the  interactive  rule  map  of  RuleManager, 
various  indicators  are  used  to  show  the  actions  during  the  trace.  A  rule  or  variable 
highlighted  in  Yellow,  indicates  that  a  rule  or  variable  is  currently  being  sourced.  A  rule 
depicted  in  Red  indicates  that  the  rule  did  not  fire  (execute)  from  the  ruleset.  A  rule 
shown  highlighted  in  Green  indicates  that  the  rule  did  fire  and  the  result  of  that  firing  is 
also  shown  in  the  green  highlighted  box  with  the  predicate  name.  Pop-up  dialog  boxes 
shown  in  the  trace  indicate  the  sourcing  of  a  variable  or  predicate  that  would  be  done  by 
an  external  entity  (service)  or  taken  from  XML  attributes  attached  to  the  query  upon 
origination  (i.e.,  user  role  and  user  security  level). 
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^  AlHtSD  Secret  IB 


^  Alert  OflIcTS  IB 


.31  SO  Harbermairtef  query  a  valid  destinaticiri 


iSl  Oakland  Karhertnaitet  query  i$  valid  destination  2 


jjJ  OeWamd  karbormaste#  qwery  it  vaaid  deitinatln 
JSIIB  Resvlts-O^ 


:3J  Alect  SO  TSIB  2 


^IBResultt2  ^€WOq«ryH  valid 


^  Oaldand  Harbotmaitef  query  b  valid  originalkin 


Term  'User_Secunty_Level'  Sourced,  [click  on  that  flashing  thing  to  continue] 


Tntet«tiv#Rul*Msp 
Kate  ■ - Q - 


T: 


^  IB  a^.  J-ii  SD  HirtmmBtg  quww  it  valid  cukiiniflioft  2 1 
.^IBResulli4  JlEResultsi 


J3l  Alert  Oak  Secret  IB 

jA  Ated  Oak  JU'  SO  H«t«nustef dutindtilqn  2)  cpuery  b  valid  2 


al  Alert  SO  ^  Alert  SD  Secret  D  2 


^AtertOakTSIBl. 


^JheTi^Scan^JLeyet 


[Zj  SD  Haibormaster  qM«y  M  vaBd  oriqinationl 

^  Oaldand  Harbcumaster  query  b  valid  Dnginatian2 
^  Alert  SD  Secret  IB 


^  SD  Harbormartfif  query  b  valid  destination  ^  Oaldand  Karhermaste#  query  i$  valid  destination  2 

J3J  Oakland  karbcrmaitef  query  it  valid  deitination 
^tSBesultaS  :3l]&R«ultl<J2 

jyAleciSDTSIB2 

®  I  jil  B  Results  2  ^  qoeqr  b  valid 


ji  Alert  OakTSIB 


Oaldand  Harbormaster  query  b  valid  oiiginatiDrv 
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Kate  ij - 

I 


■31  IB  SO  HirtiOfrftKitg  <niww  it  viilid  wiaiimioft  2 1 

^  IB  Rfsutls  4  ^  ResuHs  1 


Oakland  Harbormiitcf  qwiy  is  valid  oiiginatkin 


292 


Trttet«tiveJUil*Map 

Kate  ij 


^labet 


^  SO  HaifaoniMilEr  qiwy  K  ctestiiulwn  2 

Oakland  Haibcrmaster  quay  is  valid  (HigmatiDn 


I^SQHaifaonnastgwwitvaSd  oriainanionl 


^  Oakland  HartTcnnastar  qu«y  is  valid  originafti^n  2 
^  Oakland  Hadio 


'm  V«^Clasi^catiii»,ljeval 


Harbarmastar  quaty  is  valid  dasUnatian 


|^SOH*rf»nnMtefCiuMvitvaWoriairnition2l 
^  Oakland  Hutanma^ar  queiy  is  valid  daslinatiDn 
:3l  EWO  quaiy  js  vabd  2 


Terni  'Usaf_S«cunty_LHel'  Souncad.  [click  on  that  flashing  thing  to  cnntinua'] 


[nt«tKtiv«f|ukMep 
Kate  ■ - Q — 


^labat 


13 


T 


i  SpHM^rm*^  qu^  it.yaU  dcitin^n  2 1 


It  Va»(_0«stkHtliin„Port 

I  SmOaof 

Jil  OaHand  Harttormastcf  quary  is  valid  daStination  2  ^  Oakland  hteiborrAast^  qiK<y  H  valid  d'cStinatran 


jaiSOHafbflrmastff  q««y  «  valid  dastinaticin 


9 


Jam)  'Usac_Secunty_LNel'  Souncad.  [click  on  that  flashing  thing  to  cantinua'] 
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Kate  Q - 


^labet 


Q 


T' 

I 


I JLISO  HarboTOMte  auayfeviKd  datkMtionil 


1 1  Vcf9«l,Oeflina1i0n_pDrt 

J  SmOm 

Jill  OaUand  HflrtnrmfTt v  query  is  valid  destination  2  Ogi;land  hteitHnVbaitdT  qiKty  ii  valid  d'cStinatwri 


l-JSDHBibomwatf  qow  itvadid  digtinationl 


9 


Rute  'Oakland  Harbormaster  query  is  valid  ofi^inab'on  2'  did  not  Rre.  [clitk  on  that  flashing  thing  to  continue] 
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Kate  Q - 


^labet 


Q 


T' 

I 


IjlISO  HarboTOMte  auayfeviKd  datkMtionil 


It  VcsKH_0estin*1iof>_Port 

_ _ _J _ SonOopo^ _ 

l.ljOatlwdHaiiiornvirtgquHVBViiidrfertiMtiQnil  Oakland  hteibormortw  qiKiy  is  valid  deStinatwn 


1-JSDHBiboimaatf  qow  isvadk)  dieitimrtipnl 


Rute 'Oakland  Harbormaster  query  Is  valid  destinaban  2'  did  not  Ffe,  [click  on  lhat  flashing  tbin^  to  continuo] 
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Kile  Q - SUbet 

j] 

I 


0 


^EWD  query  ii  valid 


C3i  EWO  qiKiy  4  v«lrd  2 


JilQtKry  tf  Valid 


"  EW(>.VdBd_Qiiefy 


query  ij  ^eUd 


IjllOuffylnvaiMl 


Term  'EW10_Vilid_Queiy'  Sourced,  [diclc  an  that  (Teshmj  thing  to  continue] 
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Kate  {) - 


0 


^  EWO  qu«y  is  vaRid 


^EWO  qucfysvilhdZ 


^  query  is.  Valid 


'  EWOV^QiMiy 


l-niEWOouttvitirtvaMl 


j^QpiayhiivarMl, 


9 


Rute'EWO  qucfy  K  invalid*  Find,  [click  on  that  Clashing  thing  to  contmue] 


Tntet«tiv*Hul*Map 
Kate  ■ - Q - 


Mi 


^  EWO  qu«y  is  valid 

l^£WOoiMi¥it«1>d2l 


^  query  is  Valid 


^  EWOVdUQiMfy 

Fgifi- 


l-nJEWDouttviiinvatidi 


i^Qiieiyhiivilidi 


Rute 'EWO  query  H  valid  2*  did  iwtfirb  [click  on  that  Clashing  thing  to  conlinuel 
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Kate  Q - ^  labet  G 

^ 

I  ^  two  quay  is  valid  I  , _ , 

I  l-~J  £WO  BMny  it  valid  2 1 


EWO.Vdfal_Qii«y 

I  /«(>» 

^  query  is  Valid 


I  :UEWO  Quay  it  invalid  [ 


j^QqeiyWarMl! 


9 


Rute  ‘EWO  quay  is  talicf  did  not  fine,  fclkk  on  Chat  flasfMn^  thing  to  continue] 


Tntet«tiv#Rul*Map 
Kate  ■ - Q - 


^  Negartive  ID  Response  to  IE  for  Alat 
^  query  is  VaBd  ^  (Q  01 


,^BRe«]to2li 


I  VM  C^Hty 

mf 


ii  Positive  ID  Bm^  Qyaylhvafidi* 


ZLl  ]B  Rsiilts  0  J 

ResuhsO 


^  B  Results  OiJ 
^AJeit  Hotifkiftion  b  Absent 


Rule  'EWO  quety  b  relief  did  not  fine,  [click  on  Chat  flashing  thing  to  continue] 
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Kate  Q - 

I 


^labet 


0 


^  Ne^aitive  ID  Response  ta  IE  for  Alot 


Query  ii  Valid 


RHvttlOl 


1^' 


I  QuHy 

mf 


■UJ  PcBitMfi  ID  Reij 


ZLl  ]B  RcfulU  0  J 

Results  a 


^  B  Results 
^AJeit  MctifkaticKfi  b  Ahserrt 


be 


9 


Rute '<^efy  Invalid'  Etied.  [click  on  thst  nashing  thin^  to  CDnUnuel 


Trttet«tiv*Rul*Map 
Kate  ■ - Q — 


i'^  Query  is  Valid 


^  Negative  ID  Respcnia  t&  IE  fer  AJut 

:^IBR<Sutti04 


-  Vdy,Qii«r 

Tiv9 


3jPuiitrve  K>  Res(  izIQueiylnvaidl^ 


Result!  DJ 

Results  0  41IIER«ults04 

^  Alert  MotifKatian  b  Abseftt 


Rute  'Query  b  Valid'  b  irt  progress,  [click  on  d^at  Eashing  thing  lo  continue] 
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Trttet«tiveJUil*Map 
Kate  Q - 

e»| 

I 


^labet 


0 


^  Negative  ID  Respcnie  IB  fer  Alert 

I^CtuayiiVii^  j3l  IB  B«ulti  04, 


-  v^,Qii«r 

7i^ 


^pDiitiviG  ID  M::JQtfWlnvgW]rt 


^  IS  RkuIU  □  J 

Results  0  JIU  IB  RKiAi  04 

^  Ahrt  l^otifKatian  is  Absent 


si 


9 


Rute  ‘<^efy  is  Valid'  fired,  [click  on  that  flashing  thing  to  continue] 


Tntet«tiv#Rul*Msp 
Kate  ■ - Q - 


O: 


.31  ID  Rejportje  t*  15  lot  Alert 

^IB  Results  2 

-J  E  Resulti  i  _3j  IE  Rauiti  (|j; 


^  Rositive  ID  Response  to  IB  for  Alert 


3136  RcHilts04 


Jl  IB  Reeuhs  03 


9 


Term  lB_RespDnse_Waet'  Sourced,  [click  on  that  fTeshing  thing  to  continue] 
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Kate  Q 


^labet 


0 


o 


^  Atert  NotfTicitiQn  ii  Present 


^  N^altive  ID  Responie  to  IB  for  Alert ; 


PofitrvelD  Re^p^nsetn  18  f^r  Alert 


^  Alert  hfotificetion  rt  Absent 


Temt  'Query^RHttiines_DatBjn£erti{>n'  Sntsfced.  [click  on  that  fiasltin^  ltHn9  tn  continue] 


[ntet«tiv*Rul*Mflp 
Kate  ■ - Q - 


O: 


^  Alert  Oakt^ez 

Jll  Alert  Oak  £«<reiJS 


JSl  Atert  SG  T5  ]B .  ^  Altrt  SO  Setre*  ]& 


Alert  Cak  ^rvt  16  2 


^  Alert  Nottfication  is  Present  I  foe  Rote  Locartian 


i^Alert  SO  Secret  ]BZ 


Term  A I  eft,Pfiesent_  Response'  Sourced,  [click  on  that  fieshing  thing  to  condnue] 
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Trttet«tiveJUil*Map 
Kate  Q - 

e»| 

I 


^labet 


Q 


:LjAtertOaliT5]B2 


zd  Alert  Dak  Secnt  IE  2 


ZSJ  Alert  hot  Valid  Tot  Role  Location 


^  Alnt_rtotifkxttDn 


OJ  Alert  SO  Secret  IB 


^AJertSOTSlBi 


^IB  Results  2 

^  Alert  SD  Secret  IB  2 


^  Alert  OakTS  ^  ^ Oah  Secret  IB 

^  IB  Results  0^ 


be 


Term  'Alert^Ncrti'ficatfDri'  Sourced,  [click  on  that  llastitn^thmg  to  cootinue] 


[rttet«tiv*Jtul*Msp 
Kate  ■ - Q - 


T: 


HjAtertOakTSIBJ 


ResuftsQJ 

Alert  Dak  Secret  IB  2 


ZU  Alert  hot  Valid  fat  Role  [.ocetion 


%  Alert_Hotif)a^ 


Alert  SO  Secret  IB 


^  Alert  SOTS  IB  2 


f 


IB  Results  2 

^AJertSDSecretlB2 


■31  Alert  OakTS  ^  ^  Oak  Secret  IB 

^  IB  Results  02 
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Kate  Q - 


^labet 


T' 

I 


0 


:ilAtertOaltT5]BI 


Trttet«tiv*Rul*Map 
Kate  ■ - Q - 


^  Aten  Metilkaftjan  Es  Present 


^  Alert  OalcTSIB2 


^AtertOal:  Secret  IS  2 
,□1  Alert  Hot  Valid  for  Role  LscatiDn 


:2lAleftS0TSIB2 


I  ^  Alat  Mrtjficdtion  a  Absent  [ 


'  Meet  h^seiit_lt«p«ifir 
Ft^ 


;2jAleitSDS«retlS2 


Alert  Oak  Secret  IB 


jSlAlertWTSlB 


Alert  SDWwt  IB 

31  Alert  OikTSie 


Term  'Aler^Ncitiftcalion'  Sourced,  [click  on  thalllashiing  thiog  to  cemtinuo] 
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Trttet«tiveJUil*Map 

Kate  ij - ^ 

V 

I 

jal  Alert  SOTS  IB  ^ 

I  ^  Alert  Notify  Jtian  is  AbiaVtl 

■  Alert  (Yesent  Response 

me _ 

^  Alert  SD  Secret  i  [  Til  Mo  Ate*!  IP  j 


^  Aten  Net  ilk  aftj  an  Es  Present 


^  Alert  OakTSiB2 


^  Atert  Oak  Secret  IS  2 
Alert  Hot  Valict  for  Rale  Lacatipn 


j^AltrtOefc  Secret  IS 


JSJ  Alert  SOTS  IB 


Alert  SO  Secret  IB 

31  Alert  OikTSIB 


Rute'Mo  Alert  IB' fired,  [click  on  that  Flashing  thing  Do  continue] 


Tntet«tivieRul*Msp 
Kate  ■ - Q — 


T 


3lAlertS0TSIB2 


1 Alert  MrtjTiEation  k  Absent  | 


*  Alert  Preseiit_R«pDiw 

me _ 

Alert  SD  Secret  tS  2  |  Mn  AteHSj 


^  Alert  Netilkatlan  Es  Present 


1 3J  Alert  QakTSiB2| 


3l  Akrt  Oek  Secret  IS  1 
3l  Alert  Hot  Valid  for  Role  LacatiDn 


3lAltrtOBl:  Secret  IS 


31  Alert  SOTS  IB 


3J  Alert  SDS« ret  IB 

3lAlert04kTSIB 


Rule  'Alert  OalcTS  IB  2'  did  not  Fire,  [click  on  that  flashing  Efung  to  ccmtinue[ 
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Kate  Q  - 

I 


^labet 


0 


^  Aten  Net  ilk  aftj  an  Es  Present 


|^A]crtQakTSiB^| 


^  Atert  Oak  Secret  IS  2 
Alert  HdE  Valid  ferRDle  Lacatipn 


::alAleft  SO  TSIB  ^ 


I  ^  Alert  Notifpc  Jtion  ttAfasertl 


Alert  SD  Secret  IS  2 


IjJJNoAiemBi 


^  Alert  Oak  Secret  IB 


Jiil  Alert  SOTS  IB 


:3JAJertSDS«cetIB 


I-IJ  Alert  0ale7s¥l 


Rute  ‘Alert  OakTS  IB‘  did  net  fkA.  [click  on  that  Hashing  tiding  to  contmue^ 


Tntet«tiv*Rul*Map 
Kate  ■ - Q - 


^  Alert  Netilkartian  Es  Present 


Ij^AlcrtQakTSIBal 


I^AtertOiii  Secret  1821 

,□1  Alert  Hrjt  Valid  fer  Role  LacatiDn 


:2l  Alert  SOTS  IB  J 


!  ^  Alat  Mrtification  a  Absent  [ 


'  Alert  h^seiit_lt«|HMW 
Feift 


Alert  SD  Secret  IS  2 


1:^  Wo  Alert  b1 


Alert  Oek  Secret  IB 


Sll  Alert  SOTS  IB 


:2J  Alert  SDS«wt  II 


l-U  Alert  Oafcfs^l 


Rute 'Alert  Oak  Secret  EB  2'  did  not  tire,  [click  en  that  Hashing  thing  to  conlinuel 
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Trttet«tiv*fUil*Map 

Kate  [J 


¥l 


^labet 


^  Aten  Net  ilk  aftj  an  Es  Present 


|^A]crtQakTSiB^| 


I -lAkrtOtit StCftt]B2l 

Alert  Hot  Valid  ferRDle  Lacatipn 


::alAleft  SO  TSIB  ^ 


i  ^  Alert  Notifpcjtign  ttAfasertl 


^  Alert  SD  Secret  IS  2 


I^AkrtOifcSMfttlBl 


IjJJNoAiemBi 


Jiil  Alert  SOTS  IB 


:3JAJertSDS«cetII 


I^AlBt  OaleTS^ 


Rute ‘Alert  Oak  Secret  EB'  did  net  Flee  fclkk  on  that  flashing  thkig  to  enntinu#] 


TntetKtiveRuleMap 
Kate  ■ - Q - 


^  Alert  Netilkaftian  Es  Present 


Ij^AlertQekTSIBal 


IjjAtertOiii  Secret  1821 

,□1  Alert  Hot  Valid  for  Role  LacatiDn 


IjJAIctSOTSPZl 


!  ^  Alat  Mrtifiedtion  a  Absent  [ 


'  Alert  heHiit_ltes|HMW 


Alert  SD  Secret  IS  2 


1:^  Wo  Alert  b1 


l-JAkrtOaltSecfrtlBl 


Alert  SOTS  IB 


:2JAIertSDS«eetIl 


l-U  Alert  Oafcfs^l 


Rule 'Alert  SOTS  IB  2'  did  not  fire  [click  on  that  flashing  thing  to  continue] 
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Trttet«tiv*fUil*Map 

Kate  [J 


¥l 


^labet 


^  Aten  Net  ilk  aftj  an  Es  Present 


|^A]crtQakTSiB^| 


IjJAkrtOtfc  StCftt]B2l 

i^Aleit  Hot  Valid  fer  Rale  Lacatipn 


i  ^  Alert  Notifpcjtign  ttflfasertl 


^  Alert  SD  Secret  IS  i 


I^AkrtOifcSdCfttlBl 


I:jJ  No  Alert  bI 


[JJ  Alert  SO 


:3iAJertSDS«cetII 


l-:j  Alert  OaleTS^ 


Rute  ‘Alert  SOTS  IB'  did  net  fka.  [cNch  en  that  flashing  Ihin^  ts  ceeefivue|[ 


TntetKtive  Rule  Map 
Kate  ■ - Q — 


^  Alert  Netilkatian  Es  Present 


Ej  Alert  aakTsiBil 

!  Alat  Nrtjficdtion  a  Absent  [ 

|-JAIertS0SeciitB2| 


IjjAtertOiii  Secret  IB2l 

,□1  Alert  Not  Valid  fer  Role  LacatiDn 


IjJ  Alert  50  TSPZl 


'  Alert  h^eHiit_ltes|HMW 


Ij^NoAlertlBl 


l-JAkrtOifcSecretlBl 


|jJ  Alert  SO  TSBl 


:2JAIertSDS«eetIl 


1^  Alert  Oalefs^ 


Rute  'Alert  SO  Secret  IB  2'  did  not  fire,  {click  on  that  flaslting  thing  to  continue] 
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Trttet«tiv<fUil*Map 
Kate  Q 


¥l 


^labet 


^  Aten  Net  ilk  aftj  an  Es  Present 


|^A]crtQakTSiB^| 


I -lAkrtOafc Stcftt]B2l 

i^Aleit  HdE  Valid  fer  Rale  Lacatipn 


i  ^  Alert  Notifpcjtign  ttflfasertl 


l;-J  Alert  SO  S«ratB2| 


I:jJ  No  Alert  bI 


I^AkrtOifcSecfetlBl 


[JJ  Alert  SO 


IjJ  Alert  SO  Secret  B I 


l-:j  Alert  OafcTS^ 


Rule ‘Alert  SO  SecrertlB'  did  not  fire,  [dick  on  that  Hashing  thing  Do  continue] 


Tntet«tive  Rule  Map 
Kate  ■ - Q - 


^  Aten  Netilkatian  is  Present 


, - .  I^AkrtOth  Secret  ]B2l 


IjJ  Alert  50  TSPZl 


!  Alat  Nrtjficdtion  a  Absent  [ 

I -J  Alert  SO  Secret  B2| 


'  Alert  heHiit_ltesp«ifie 


Ij^NoAlertlBl 


l-JAkrtOaltSecrrtlBl 


[jJAtertSOTSBl 


1^  Alert  SO  Secrete  I 


l-U  Alert  OafcTSlBl 


Rule 'Alert  Not  Valid  for  Rote  location'  fired,  [click  on  that  flashing  thiirg  to  continue] 
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Kate  Q - 

I 


^labet 


0 


^  Alcft  Motificctiwi  h  Present 


.Hi  Altrt  HotificflliQn  «  Abaend 


Megjtrvg  ID  Rapangt  tfl  IB  for  PJert  | 


'  Qy«y_Reqiiir«_Data_tn»ftkiii 


Positive  9>  RespoiKe  to  EG  f(K  Alert 


Rute ‘Alert  Not  Valid  Far  Rote  I ocarti on'  fired,  [clkk  am  that  ftasliin^  thing  to  continue] 


Tntet«tiviefUil*Mflp 


AlEft  Mottficetirm  is  Present 


I^Aiert  MatificBtionHAIwBit] 

Megjtrve  ID  Raportw  tn  IB  for  AJrt  | 


Positive  ED  Respoime  to  EG  for  Alert 


Rute 'Alert  NotiFicelnn  is  Absent'  fired,  [dick  on  that  flashing  thing  to  continue! 
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Kate  Q - 

I 


^labet 


0 


I  -il  Atert  Motificrtkin  it  Prtttn^ 


zj  iMtrt  MotSicgtion  ii  Alwent  | 


_~J  Megjtjvg  ID  Rapangt  tfl  IB  for  ^ert  | 


'  Qy«y_R«qiiir«_Data_tn»ftnii 


Poiitivie  RespoiKr  to  EB  fw  Alert 


9 


Rute  ‘Alert  Natifical»n  is  Present'  did  not  Fire,  [click  on  tFiet  Iteshin^  thing  to  ctmtinue] 


Tntet«tiv*Rul*Mflp 
Kate  ■ - Q — 


:^eiteHiits_24] 


:3i  Pnsitivft  ID  R«f»nie  to  3B  for  Alert  etoffiJdfA^ 


'  IB^Rcspofisc^Watt 


^  IB  Results  OJ 


Fte$ulb0.2 


Rute 'Alert  NotiFieelnn  is  Present'  did  not  Fire,  [click  on  that  dashing  thing  tn  ctmtintie] 
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Kate  Q - 

I 


^labet 


0 


jyjBltc^_24] 


:U  PwitivaiD  RMpMnffttQ  3B  ft,t  Alwt  e »«  B  fw  Afert  | 


*  IB  RiEspofisc  Walt 


^IB  ReMihsOl 


be 


9 


Rute  Tte^Sivs  ID  Response  lo  E  for  Aterl^  tired,  [click  on  that  fieshin^  Ihin9  to  continue] 


Tntet«tiv*Rul*Mflp 
Kate  ■ - Q — 


^3 


:^eiteHite_24] 


J3j  Positiwft  ID  I  -J  fteqatiire  B?  B^ponse  In  B  fof  Atert  | 


^  IB  Results  OJ 


jyeRfsuitiOJ 


^]BR«$ulbOJ 


Rute'Me^alive  ID  Response  Id  E  for  Atesl^  fired,  [click  on  that  flashing  !hin9  to  continue] 
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Kate  Q - 

I 


^labet 


0 


-:yjBitc^_24] 


[  ~ I  PiKitjyic ipf^  fteqativie  to  IB fw  Afert | 


*  1B,RiEspofisc„W^ 


^  IB  Results  m 


be 


Rute 'Posftivr  ID  Rievpam«  to  IB  for  Alert'  did  not  fire,  (elicit  en  that  flashing  thin^  to  continue^ 


Tntet«tiv*Rul*Mflp 
Kate  ■ - Q — 


^3 


I^PRauteni 


I  -iPiMjriyelpl^MeqatiwielD  RejpgMeliPlB  fof  AfertJ 


'  IB^Rcspofisc^Watt 


^18  Results  OJ 


j;U]BR«$ulbCiJ 


RutelB  Results  ?nl'did  rwt  Ihk.  [dick  en  that  flashing  Ihin^  to  tontinuel 
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Kate  Q - 

I 


^labet 


G 


l-JIBRcHiIttni 


[  ~ I  PiKitjyic ipf^  fteqativie  to  IB fw  Afert | 


*  1B,RiEspofisc„W^ 


^  IB  Results  m 


I^PRqtlUlPJl 


be 


Rute’IB  ResulU  Q.3'  did  rwt  [dickon  ait  flesh fng  thin^  to  £onCknue| 


Trttet«tiv#Rul*Map 
Kate  ■ - Q - 


I  -iPiMjriyelpl^MeqatiwielD  RejpgMeliPlB  fof  AtertJ 


'  IB^Rcspofisc^Watt 


^  IB  Results  OJ 


I^PRwiHlOn 


I^IBRttulbOll 


RutelB  Results  O.Z'  did  rwt  Ihk.  [dick  en  than  flashing  Ihin^  to  contiinuel 
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TAtet«tiv*fUil*Map 
Kate  Q 


^labet 


l-JIBRcHiIttni 


[  ~ I  PiKitjyic ipf^  fteqativie  to  IB fw  Afert | 


'  1B,RiEspofisc„W^ 


I^PBtKiHipJl 


l^gRttuiaoI] 


Rute  ’IB  RasuIU  Q.1’  did  rwt  [dick  on  tl^ait  flaihfng  thirty  to  £onCmue| 


Trttet«tiv#Rul*Map 
Kate  ■ - Q - 


i^pRcdteni 


I  -iPiMjriyelpl^fteqatiwielD  RejpgMeliPlB  fof  AfertJ 


'  IB^Rcipofisc^Watt 


I^PBtttlUlOn 


I^IBRtaulbOll 


RutelB  RfiSulU  6'  did  not  fire,  (click  on  that  Hashing  thing  tn  continiw] 
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TAtet«tiv*fUil*Map 
Kate  Q 


^labet 


l-JIBRcHiIttni 


[  ~ I  PiKitjyic ipf^  fteqativie  to  IB fw  Afert | 


'  1B,RiEspofisc„W^ 


IjjgHwumsI 


I^PBtKiHipJl 


l^gRttuiaoI] 


Rute  ’IB  RjsuIU  5-'  c^d  not  lire,  (cliclc  an  that  llashin^  thing  to  cantiniw] 


Tntet«tiv#Rul*Map 

KBte  ■ - Q - 


I^BResufaH] 


Vlmt^fluub^m  Uxitss/HiiFfS 


UlBRenjIbOj] 


|^IPHjBuft¥<i 


IjJPRtaitsOil 


Rute  IB  Results  4 '  is  in  ptogpEss.  [click  on  that  fleshing  thing  ta  ceneinue[ 
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Kate  Q - ^  labet  G 


c>: 


I 


^16  tteiults  j 


touted 


|^BBaiultsa3-] 


I^BRcufaH] 


UlSRcajIbOj] 


%  RnumJB.Reuiltf 

Vhd^ii^fE 

^  t-HPRauftsOil 

iSlIERfiSuftf^ 


ZLl  B  Resulba 


Rute  ’IB  RasuIEs  4'  Imd.  [clFck  □(!  that  Hashing  thfng  In  ccmtinun] 


Trttet«tivieRul*Map 
Kate  ■ - Q - 


l^gBwuR*^ 


I^BRemftiOGj 


I^BRbuRsII] 


T  |jjPltiKite3| 


•b  RetuiTLlB.llesulti 


UBRenjIbOj] 

I^IBRsu^ 


IjJPRtaitsOil 


|^Pa«ufaS] 


RutelB  Rfisulti  did  not  fire,  (click  on  diet  nashing  thing  tn  cantinu*] 
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__  U - m  ^ 


I 


|jJBIttKite3l 


touted 


|^BBaiultsa3-] 


I^BRcufaH] 


UlSRcajIbOj] 


%  RnumJB.Reuiltf 

/UhdatsfStdfB 


ijUPRauteOll 


ZLl  B  Resulba 

|^Bfl«ufaS| 


Rute  ’IB  RasuIU  2'  d^d  not  fire,  (cliclc  an  diet  llashin^  thing  tn  cantiniw] 


Tntet«tivieRyl*Mflp 
scale  ■ - Q - 


I^BResufaH] 


•b  RetuiTLlB.llesulti 

LhdataH^dfS 


UBResubOj] 

I^IBRsu^ 


tjJPRtaltsOil 


|.^BR«ulisS] 


Rule  IB  ResulU  O'  did  not  fire,  (elicit  on  diet  nashing  thing  tn  confinun] 
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__  U - m  ^ 


I 


|jJBIttKite3l 


touted 


|^BBaiultsa3-] 


I^BRcufaH] 


UlSRcajIbOj] 


%  RnumJB.Reuiltf 

/UhdatsfStdfB 


ijUPRauteOll 


IjJBRwufa^ 


RuEt  ’IB  RasuIU  O’  did  not  fire,  (cliclc  an  diet  nashin^  thing  to  cantiniw] 


Tntet«tiv#Rul*Map 
scale  ■ - Q - 


I^BHestiftiOGj 


I^BResufaH] 


•b  RetuiTLlB.llesulti 

LhdataH^dfS 


UBResubOj] 

I^IBRsu^ 


tjJPRtaitsOil 
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APPENDIX  D.  RULE  TRACE  OF  MISUSE  CASE  PREVENTED 


The  visual  trace  of  the  ruleset  execution  was  used  to  show  that  the  misuse 


highlighted  by  the  Misuse  Case  and  accounted  for  in  the  Security  Use  Case  is  prevented 


through  the  RuleML  ruleset.  This  trace  is  completed  using  the  following  parameters: 


Type  of  query: 

Role  /  Actor: 

Location: 

Security  Level: 

Alert  Present: 

Alert  Classification  Level: 
Expected  Result: 


Destination  Port 

Harbormaster 

San  Diego 

Unclassified 

True 

Secret 

“Vessel  Results  from  Unclassified  IB”  with  ID 
Injection  for  Port  of  San  Diego” 


The  expected  result  from  this  query  and  the  RuleML  execution  is  an  IB  response  of 
“Vessel  Results  from  Unclassified  IB  with  ID  Injection  for  Port  of  San  Diego”  to  the 
user.  The  trace  was  completed  using  RuleManager’s  Interactive  Rule  Map  functionality. 
The  pop-up  boxes  shown  throughout  the  trace  indicate  the  sourcing  of  predicates  that 
would  be  included  with  tagged  data  in  a  live  system.  This  was  not  replicated  for  this 
research  and  instead  was  manually  inserted  via  the  dialog  boxes. 

For  the  rule  trace  shown  and  from  the  interactive  rule  map  of  RuleManager, 
various  indicators  are  used  to  show  the  actions  during  the  trace.  A  rule  or  variable 
highlighted  in  Yellow,  indicates  that  a  rule  or  variable  is  currently  being  sourced.  A  rule 
depicted  in  Red  indicates  that  the  rule  did  not  fire  (execute)  from  the  ruleset.  A  rule 
shown  highlighted  in  Green  indicates  that  the  rule  did  fire  and  the  result  of  that  firing  is 
also  shown  in  the  green  highlighted  box  with  the  predicate  name.  Pop-up  dialog  boxes 
shown  in  the  trace  indicate  the  sourcing  of  a  variable  or  predicate  that  would  be  done  by 
an  external  entity  (service)  or  taken  from  XML  attributes  attached  to  the  query  upon 
origination  (i.e.,  user  role  and  user  security  level). 
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TAtet«tiv#fUil*Map 
Kate  Q 

O' 


^labet 


^IB  ReuilbDJ 


4  RetunOlE' 


JSJIB  RnvItfOJ 


Show 

TermVfclu* 

Rcic!  Temt 
Rnot  All  Vaiu» 

SIS’SkuSCJ 


Trttet«tiv*Rul*Map 
Kate  ■ - Q — 


O; 


Results  & 

^  Alctt  NOtKpcatiDH  is  Absent 


JSI  IS  Results  0-1 


ISlQueiy  is  Valid 


‘  VMSl^  ^ERsultsS 

l-^tBResufag-l! 


gj  IB  Rjesults 


1^  Posittm  S>  Respoflix  te  E  for  Alert 


OllBReaultiOJ 


Results  3  ^  Uegattve  D  Response  to  IB  for  Alert 

~Jl  Query  Invalid 


Term  ’Valtd^Query'  Soutxed.  fclkk  on  Ehal  flashing  thing  to  continue] 
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Trttet«tiv<JUil*Map 
Kate  Q 


1^1 


^labet 


•^HM  q,uefyis  liivi^ld 


Qahland  hhibormastef  quEiy  is  valid  efestinati«n  Z 


^  SO  Hadjornustef  quciy  is  valid  ofigination 

-  HM,VdlU_Qyi>f7 


SO  HartwiTvyjrtp  qwwy  e  valid  ct«tift«tiipfi 


•31  QuMy  ii  Valid 


H^OakteFvd  Harbarmastcr  quety  is  valid  dcstmatjan 


^Oiltlind  Cfuey  is  valid  origination  J 


■^fn  qgety  ii  valid  orminaticn  Z 

•31  Oaidand  HafKrfnastef  qito<y  es  valid  ongmalion 


Term  'KM.Valid,'QiJ«y‘  Sourced,  [click  on  that  fladhinq  Ehing' to  continue] 


[ntetaotivefUil*Mflp 
Kate  ■ - Q - 


9> 


^  Oaldand  HarbormaStcf  query  is  valid  destination 


AtectDak  Secret  IB 

^AJotSOSecretlEZ 


•21 EWO  queey  is  invalid 
^  SO  Harbormaater  query  is  valid  deabnatinn  Z  -3^  SO  S*ef«t  JB 


^Oaldaiid  r,rr— 

^  Oakland  Na^onnesler  queers  valid  daftmationi 


2ISC  Har^maHet  qw&y  itvjJid  destination 


^  Uw.Rote, 


^  EWO  query  is  valid 


SO  htertrOmiaster  quciy  ii  valid  onginalion  1  ]B  2 


uilAlert  SO  TSIB  2 


□d  SO  hfartKirmaiter  query  is  valid  ofiginatrcin 


Alert  OakTSIQ 

^  Oakland  Hadaoirnaatcr  queqrisvalid  rarigmation^ 


^  EWO  query  is  valid  Z 

21  Alert  OekTSIBJ 


Term  'U5er_flic![e'  Sourced,  [cliclc  on  that  dashing  thing  Do  continue] 


323 


Trttet«tiv*fUil*Msp 
scale  ■ - Q — 


4>; 
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Trttet«tiveJUil*Map 
Kate  Q  - 

I 


^labet 


0 


-7j  QuHyinvtBidI  ^  Oakbnd  HarbcMmader  quety  is  vaQd  destination  2 

JSI  0«w*nct  Hertieffflistet  qwe^  bs  valid  Originetion  ^  OaWond  Harbwmaiter  query  is  valid  deitinrtion 


^  HM  q.<iiey  is  inwaiid  |  . 


^  HlMI.V:rihl_Qii«y 


^  SO  Haifadtiviaster  qv^  4  valid  destination  2 


JilSD  Herhomastef  query  r/aJid^^nati^"''*"^  “  ^  queiy  S  v-W  originotionl 


is  Valid 

^  SO  Harbormastef  query  is  va^id  □ngiiution 


Term  'Usef ftD[e'  SouncedL  (click  on  that  (lashing  thing  Id  continue] 
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Trttet«tiveJUil*Map 

Kate  Q  -  ^  Q 

I 

cpi 

^  i  Jjj  QueQT  j  ^  Oa  Mind  Hirb^nnKter  iqy«(yi*v9Jid'dest>ti#tio«2 

OJ  Oakland  Haibormarttr  quay  is  valid  wiqmation  ^  Haibomwita  quay  is  valid  d«ti wSion 


[ ^  HM  ww  ifw^d] 


^SO  Harbunnasta  qucty  is  valid  destination  2 


^  Oakland  KiiFti«nTiasta  quay  is  valid 
:3IS0  Maibonnasta  quay  4  valid  destination _ ^ _ 

I  ^  SO  HflfbofTTMSta  quay  is  valid  oiigiMiiQn  2  \ 


^  Quay  is  Valid 

^  ^  hterboimasta  quay  is  valid  ariginatioFii 


IS 


Rute'SD  Narbomusta  quay  s  valid -cirfgirulidn  2'  did  not  fire,  [click  on  that  flash irv^  thirty  tn  continue^ 
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Trttet«tiveJUil*Map 
Kate  Q 

I 


^labet 


[_JSDH*rl?<ym«tefquwiiv<iictotiQiftiitt<>n2i 

QjOakiafid  KarlHjrmaEtef  query  is  valid  originalien  2 
iJ  Oihland  Hubornuitcr  query  is  valid  cteitinitiQrv 


^  Oakland  Harbormaster  query  is  valid  origination  ^  SO  Harbormaster  query  is  vahd  dEstrnatron 

^  Sp  Harr^rirriMa  a  valid  o^bstlii^ 

^  OsUafrd  Maitonnssier  quesyii  valid  dKtin^iionl 

^  SD  Harbonnaster  query  is  vald  destination  2 


Term  'KM_Quenef'  Sou  reed,  [click  on  that  flashing  thing  to  conlinuel 
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TAtet«tiv*fUil*Map 
Kate  Q 


^labet 


The  Harbormaster  Query  Type  wandow  opens 


Mut  li  vrfus  of  HM.QuetiH 

Sgled  avAjc 

,q;.  Onfliinitin([,Rort  Ouery 

I  DestinaAioo  PonQuety  I 


i  valid  origiitalien  2 


Select  the  Destination_Port  Query  radio  biJtton 


|.  DffitUig*  ]  [  Agply  I  [._  Canwi 


wmm 


quctyisvihd  dEitinitnDn 

jfmMter  qmry  I 


Trttet«tiviertul*Msp 

Kate  ■ - Q -  g]lai*t  - 0 
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Trttet«tiveJUil*Map 
Kate  Q 

I 


^labet 


[_JSDH*rl?<ym«tefquwiiv<iictotiQiftiitt<>n2i 

Qj  Oakland  HarlHjrmaEtef  query  is  valid  originalien  2 
^  Oihland  Hubormaitcr  query  is  viI'nI  (teitinaligr> 


%  HM.Qswrin 

OsaSts^iafi^ffat  (ktay 


^Oakland  Harfaurmaster  queiy  ii  valid  uriqination 


^  SD  HarbonnaTtcr  query  is  vahd  deiiinatnDri 

I  "iSDHiifaofrtiJiiittf  qutfv  itva<idQtkiinrtiOf>l 

^  OfiWafid  Marijoimsslef  qusyij  valid  d«ti<ialicir^l 

^  £D  Harbonnaster  query  «  vald  destination  2 


9 


Rute'SD  NarbomuitH  query  is  valid -DrfgirvBtTDn'  did  nortflie.  (click  cm  that  fiashrng  thing  Ea  continue] 
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Kate  [J - 


^labet 


0 


i^PoftcyOecwn  Point; 


I 


^  Policy  DKiiion  Point 


^  UlBf  ^Rol6,P«TTMn»fl9 1 


Ttfm  'Usef_ftDte,PefniiHiQns'  SeutcHd.  (clkk  on  thdt  Railnin^  thing  to  continue'] 


Tntet«tiviePul*Mflp 

Kate  ■ - Q -  S  label  - 0 


j:sf  Policy  Oeewn  Point; 


Click  the  Apply  button: 
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Kate  [J - 


^labet 


0 


o; 


I  Zl  Poftcy  Pwbkin  Point^ 


I 


^  Policy  DKiiion  Point 


^  UHr„Rate,Paniiiiii«lit 
TlttJE 


9 


Rute  'Policy  DKiaion  Point  2'  d^d  not  life,  [click  on  thart  Hashing  thin^  Eo  continue] 


Tntet«tivoRul*Mflp 
Kate  ■ - Q - 


l-::J  Policy  Oedsion  Point  2 1 


^  PoCcy  Dedsiwi  Po^ 


iSiOiMwd  HKcboriThistet  qtjecy  itvaJidi  dtstinition 

I  ^  SO  Harfaonnastef  query  «  valid  pngnatiwi  [SO  HubOffitertCf  ftutfv  it  velwl  origiMlion  2 1 


^EWO  que<y  ii  vjJi^ 


PDfJ>mdAKi 

Tjt» 


jll  SO  Hartaonna^ter  queiy  is  valid  dsltnaitjcin 


Oakland  HarbomHiitcf  quny  is  valid  dntinalnn  2 


{_JJO  HaifaptmastBr  queiy  B  vaM  destinatipn  2 1  a 

^  Oakland  Ma4lKinnaster  qu«y  is  vaHd  origination 

^  EWO  queiy  is  valid  2 

^  Oakland  hterboimastef  q^eiy  is  valid  angination2 


Rute ‘Policy  Decision  Point'  is  in  proqioss.  [click  on  that  flashing  thingi  to  conEfnue]! 


331 


Trttet«tiveJUil*Map 
Kate  Q  - 

I 

“f- 

I 


^labet 


0 


l-JPolicvOeCrtionPoint2l 

I  ^  Poli^  Decwiofi  Point  | 

Hatfcormastet  qnttiy  itvaJid  destirnti^n 

I^SD  Hartia<rmftajerqu«yiivjMgiqnJSiiii)SDHltfa«mMteffl^iB¥fcvlM  oriaifMtiOflZl 


^  E  W  ^uciy  tt  V 


POP.OkMiiii 

7a# 


lU  so  HaffcQrmafttLf  qu«y  invalid  destinalian 


Oakland  HarbotTfuiitcf  quoy  is  valid  dntinatwn  I 


I^SO  hUitKircnaiter vafid  cfaati nation 2  I 

^  Oakland  Harbofmaater  quay  is  valid  ori^natian 

^  EWO  qu«y  is  valid  2 

^  Oakland  Harbormaslcf  queiy  is  valid  adqinaticin^ 


9 


Rute  'Policy  DKlsion  Point'  tired,  (click  on  that  llaskiin^  thing  to  continuo] 


Tntet«tiv*ltul*Mflp 
Kate  ■ - Q - 


^  HarbomnaSttf  query  is  valid  destination 
Oakland  Harbiwmaiter  quety  is  valid  origination 


::dqtieiv  Invalid 


^  Oakland  Haiboimaster  queiy  is  vafid  destinabon 


-  HM  JUy_QuBfT 

Til# 


HaibonnasterqueiyB  valid  destination  2 1 


al  Queiy  is  Valid 


|jLf50HaifaonnwiefQmfviivaWofii^ai30o2| 


.in  Oakland  Hafboffnastetquefy  Is  valid  dstination  2 

l-JSt)HatbofmasttfOu«y  is  valid  originHioni 

EJWilouwitlnvalidl 


Rute  ‘Policy  Decision  Point'  tited.  (click  on  that  llashing  thing  to  continue] 
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Trttet«tiveJUil*Map 
Kate  ij - 

Ci>| 

I 


^labet 


Q 


‘SlAIntOjiirT^tR 

Oakland  Harbermadcr  quciy  ii  valid  QrigirHtiofi 


^OnkJaificI  Hertoima^tp  q^ety  ij- vflid  onginalion.  a' 
Jills  R»idtf2 


Oakland  Nartionna:ttr  quciy  is  valid  d«linalion  I 


l-iJ  SO  Hirbormaster  aii«y  it  vaiid  oftoiamioftTl 


^Est  Loealion  for  Rote 


^  Oakland  HarbwrnKtcr  query  ii  vahd  dutinartion 


JllAlwtIOTSIBJ 


I^SO  Hwbwmastef  queryti  validpfiqitTjtiqnl 

JiJAkrt  Oak5««tlBi 


l^lBRoullxU' 


,  Jil  SD  Haibcimasttf  OMfy  is  valid  destination  2 
:3JAIejtS0&«retIB2  ' 


SD  hhebormaitef  queiyB  valid  dextination 


si 


9 


Rule  'Policy  DKlaion  Point'  fmd.  (click  on  that  Dashing  thing  to  coirrtinuo] 


Tntetaetive  Rule  Map 
Kate  ■ - Q - 


^  IB  R«ulti  0 

^IB  Residts^ 

^  Alert  Oak  Secret  ]B  2  ^  IS  Results  OJ 

Jil  £WO  quety  is  valid 

^AlertSOSeeietlB 

J3l  Alert  OatTSIB 

J3IIB  RmiHsOJ  Jl^l®  Results2  jitAtertSDS«.et  IB  2 


^Aiert  Oak  Secret  IB 


JilAI^SOTSIBJ 


JiJlBRcsulti  3 
I  -Hi  SO  Harbwmastef  query  a  valid  origination  | 


%  UserjSccurilV-l-eyd ! 


^Oakland  Harfaorfoastef  query  is  valid dertinartlon  destination 2 


r  -irn  1 1  j. —  Oakland  HarbormastM  query  is  valid  onginaliDn  2 

^  SO  Harbormaster  quay  is  valid  destination  ^ _ 

|jjJ  ®  Harboimaittf  gysy  «  vaWjteflina^n  2  r 

Ij^ERtButeZli  J^AteftOakTSie2 

^Oakland  Harhormasler  query  is  vaSd  eriainatian 

jUiBriHaHni 


Term  'User_Secunty_Level'  Sourced,  (click  on  that  (lashing  thing  to  continue'] 
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Kate  Q  - 

I 

I 


^labet 


0 


^EWO  query  is  valid 


^  IB  Reautts  Oi  ib  Rgsulti  i 


^AteitSDS«KtlE2 


^AtertSOSwfet  IB 

OahTSIS 


^Alet  Oak  Secret  S 


^  '  f/ 


ItlAlcrt^OTSlSJ. 


^  IB  Raaults  3  ^ 

|_J5DHaifapimastef  queiyi>v«r>ilonginalkm| 


^  Oaktend  Hadiannaster  qu«y  is  vaiid  destHnalicin 

^  UAKuna  i-iarQMmKHr  query  rs  valid  dslin^pfi  i 


I  ~i  SD  hUitiCffl^  HarbiNTn^as  t^ucry  is  valid  origination  2 

htedMrmatttv  qut^  i(  valid  destirKtiiOti 

SO  HarfaoiTnwtef  query  i;  vtfici  deitinftiofi  2 . 

:^gnte5uits2i| 


JjAlnt  CSahtSie2 


^Oadgnd  Harbomiafttt  query  Is  vallci -unqlnetrori 
iISJlB' Ra^hf 


si 


Term  'Us«_Secunty_LHel'  Sounced.  [click  on  that  flashingi  thing  to  continue] 


Tntet«tiv*  Rule  Map 
Kate  ■ - Q - 


^EWD  query  is  valid 


;al  IB  Rsutts  Oi  IB  Rtsulti  2 


^AteftSDSacfetlBZ 


^AtedSOSecfet  IB 

^^EitOahTSte 


Alert  Oak  Secret  IB 

^  IB  Rasults  3 

IjJSPHaifapimastef  qMeiyi>v»Maiiginalipn 


^AlcdSOTSlBJ. 


»  ,  ^  Oakland  Hadiannaster  query  is  valid  destHiatiun 

'  n  ^  uanana  liarnomriKier  query  rs  vaid  destination  2 


I  ~i  SD  hiartiCfn^  ^  Harborm^er  query  is  valid  origination  2 

l31S0  htertorrtiatttv  qoeiy  invalid  deitinetton 

SOKarbormartefqueiy  isyrfid  detonation  2. 

^gfitesuitririi 


:ii)  Alert  0ahTSEe2 


^Oakland  Harbormaster  query  is  valid  onginatrori 
ResiulUtlJt 


Term  'User^SecurityJ-cvel'  Sourced,  [click  on  that  (lashing  thing  to  continue] 
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Kate  [J - 


^labet 


0 


G>\ 

I 


be 
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Kate  [J  - 


^labet 


0 


^  Oakhtid  HarbeHTTiHter  query  ii  vaEd  deslinaftian 


^  SD  Harbontiffter  queiy  it  valid  dcrti^idn 


%  Vcf9«l_Oeftinai1i0fii_pDrt 


^  Cakteimj  Harbormaster  query  ts  vaEd  dcstrnatian  2 


Jjj  SO  HMbomtefttf  vaM  datinrtioft  2 


Term  'Usef S«cudty L»el'  Sourced,  [clirkon  that  flashtngi  thing  to  continue'] 
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Kate  Q - 


^labet 


0 


^  Oakhtid  HarbeHTTiHter  query  ii  vaEd  deslinaftian 


j_JSDHirt>ofm>iteroiiCfy  it  valid  dtrtinrtioni 


%  Vcf9«l_Oeftinai1i0fii_pDrt 


^  Cakteimj  Harbormaster  query  ts  vaEd  dcstrnatian  1 


1-^  SO  Hatfaonmttef  auw  it  vaM  dcttpftrtioft  ^ 


9 


Rute ‘SD  Narbormaitef  query  it  valid  destination'  dlid  not  fire,  [click  trn  thait  Flashing  thing  to  continue 


Tntet«tiv#Rul*Map 
Kate  ■ - Q — 


(^i 


^  Oakland  Harfaofmaster  query  ii  vaEd  dstination 


j_jSDHirt>ofmattef  query  it  valid  dtrtinitioni 


t  V«»(_[>«thHtlan_Port 


^  Oakland  Harbormaster  query  is  vaEd  desbnation  2 


1-^  SO  Hatfaonmttef  cwcrv  it  vaM  deftprutiort  2] 


Rule  ‘Oakland  Harbormaster  query  is  valid  on'ginaliefi  2'  did  not  fire,  [click  on  that  flashirtg  thing  to  continue] 
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Kate  Q - 


^labet 


0 


^  Oakhtid  HarbeHTTiHter  query  ii  vaEd  deslinaftian 


j_JSDHirt>ofm>iteroiiCfy  it  valid  dtrtinrtioni 


%  Vcf9«l_Oeftinai1i0fii_pDrt 


^  Cakteimj  Harbormaster  query  ts  vaEd  dcstrnatian  1 


1-^  SO  Hatfaonmttef  auw  it  vaM  dcttpftrtioft  ^ 


9 


Rute 'Oakland  Herbormester  query  is  valid  nnqi nation'  did  not  fire,  {clkk  cm  that  flashtttg  tiring  torontlnue] 
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Kate  Q - 


^labet 


G 


I  _i  Caldand  Harbonrastef  quay  ti  valid  deslinalljon  | 


j_JSDHirt>ofm>iteroiiCfy  it  valid  dtrtinrtioni 


%  Vcf9«l_Oeftinai1i0fii_pDrt 


I^Oildind  HaAwniisto  query  H  valid  derijration  J I 


1-^  SO  Hartwnrnttef  auw  it  vaM  dcftBftrtioft  ^ 


9 


Rute'Oakiand  HarbonuMster  query  is  valid  dstination'  did  not  fine,  [click  on  'Aat  fi ashing  thing  tocontiivuej 


Tntet«tiv*fUil*Map 
Kate  ■ - Q — 


(^i 


j~iJ  fWO  qiHiy  is  vilid 


J5]Qu«y|nv4lid] 


.31  £WO  queiy  is  valid  i 

-  EWO.y.M_Qii^ 


^  EWO  qu«y  is  iirvalid 


Queiyij  Valid 


Term  'EW10_Valid_Quefy'  Sourced,  [click  on  that  flashing  thing  lo  continue] 
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Kate  [J - 


^labet 


0 


I 


JSJ  GWO  query  Ff  >ra4id  2 


^  B^O  queriT  b  valid 


■  EUVO  Vdd 


^EWO  qjuey  binviiidi 


^  QiJ«y  b  Valid 


9 


Rute  ‘EWO  qticfy  b  invalid"  ia  in  p^mi,  [click  dfi  that  ffiashing  thing  to  continue] 


Tntet«tivieRul*Map 
Kate  ■ - Q — 


Ol  BMO  quEtyb  valid 


JSJ  EWO  quay  d  vdid  2 


■  EUVO  Vdd  Queer 

faint 


jlquoyijV.lid 


Rute  "EWO  query  b  invalid'  Flred^  [click  on  that  Hashing  thing  to  continue] 
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Kate  [J - 


^labet 


0 


I 


j^EWOfluefyttvjlidll 


^  B^O  querir  b  valid 


■  EUVO  Vdd 


1.;;:^  £W0  gumy  b  invilid| 


^  QiJ«y  b  Valid 


9 


Rute'EWO  qticfy  b  valid  2'  did  lutfirt  [dick  on  that  flaihing  thiivg  to  conlinuej 


Trttet«tiv#fUil*Map 
Kate  ■ - Q — 


(^i 


I^EWOctuaybyalidl 


i^EW0fluwitva<ld2l 


■  EUVO  Vdd  QHCfr 


jlquoyijV.lid 


Rute  'EWO  qu«y  b  valicT  did  not  fina,  [click  ofi  that  flaahing  thing  to  cnntintw] 
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TAtet«tiveJUil*Map 
Kate  Q  - 

I 

I 


^labet 


0 


^Posttem  [D  RcspaiiH  te  IB  Fof  Alert 


J31B  P«ults0-3 

Q|  Alert  Noliflulian  ij  Abunt 


<■  V^,Qu«T 


lUIERttglHOJ 


Query  ii  Valid 


^  IB  ResuIIs  O' 

^  16  5 


^  Negative  JD  Response  to  IB  far  Alert 


si 


9 


Rute  ‘EWO  query  is  talicf  did  not  fire,  fclkk  on  that  flashing  thing  to  cuntinu#] 


Kate  ■ - Q - 


^^Postteve  ID  Respanie  te  CB  for  Aert 


^  IB  Peduitt  0,3 

.31  Aert  Notificatfan  is  Absent 


[-HlQMWlnvaidl 


-  V^.C|u«r 


UlIERttgteOJ 


Query  ii  Valid 


^IB  RcsuttsO 

,^16  P«ufts5 


Negathre  ID  Response  to  IB  for  Alert 


Rute 'Query  Invalid'  fired,  [elickon  that  Fleshfitg  thing  to  continue] 
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TAtet«tiv*fUil*Map 
Kate  Q 


^labet 


[D  RcspaiiH  te  IB  ftw  Alert 


::3lie  R«ultJ0-3 

131  Alert  Noliflutfon  ij  AlKent 


[jJQuwliwaBdl 


'  V^.C|ii«r 


Z;llERttgteO-2 


[^QtJgylVvaid-! 


^16  (!ciuttsB 

^  16  Pcsulk  5 


^  Negative  ID  Response  to  IB  far  Alert 


be 


9 


Rute ‘{^ery  H  Valid'  is;  in  progresa.  [elide  on  tf^at  Flashing  thing  to  eonEnue] 


Tntet«tivdRul*Mfip 
Kate  ■ - Q — 


(^i 


13 


L^JIBResnltiCJ 

i^Positeve  ID  Response  te  EB  for  Alert 


^16  P«vttt0-6 

i3l  Alert  NotificBlfan  is  Absent 


V  ■[-  " 


[jSigtfWlniVgBdl 


'  VdM.Qii«r 


lUBRetulHOJ 


l^qttBvtsVaidj 


i^l6  ResuitsB 

^16  Results  5 


Negathre  ID  Response  to  IB  far  Alert 


Rute  'Query  is  Valid'  fired,  [clkk  on  that  flashing  thing  to-  continue] 
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Kate  [J - 


^labet 


Q 


^  PoutivE  ID  Rfisponse  to  IB  for  AJeH 


^  hicqativc  K)  RcspofiK  tc  E6  fur  Atert 


'  IAJlGlfWIItC_WBt 


^  IB  RBStrtti  0,2 


,^IB  RfifiiltiOl 


Ttrm  lB_RHpDns«_Wait'  Sourced,  [cliclc  ofi  that  Reshtn^  thing  to  continue] 


Tntet«tivieRul*Map 
Kate  ■ - Q — 


(^1 


al  Al(St  Nolifitalion  is  AHenI 


;j|  Positive  ID  Response  lo  ^  f  ot  Alert 


Alert  NotificatiDn  ii  Present 


'  ,^KeqtwelD  ItesjionsetolSliprAtertj 


9 


Term  'Query_Rec[uirei_DatBjnsertjDn'  Sourced,  [click  on  that  flashing  thing  to  continue] 
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Trttet«tiv*JUil*Map 
Kate  Q 


^labet 


^Atert  MffEiAciticn  it  Abrtftt. 


^Alcft  SO  Secret  IB 

^Nd  ASstlB 


^  Alert  Oak  Secret  IB 


■  Ateft_Pres«rt_ne^i«ise 


^  Alert  Oak  Secret  t6  2 


^  Alert  ^IctifKation  is  PresenI 


jlilAlertSOTSHBl 


^  Alert  SO  Secfet  If  ^  ^  LBcalion 


Term  'Alert.Piesent^Respcinse'  Sourced,  [dick  on  tiwt  fleihing  thinc)  E9  conUnue] 


[AtetKtive  Buie  Map 
Kate  ■ - Q — 


^labet 


;t|  Alert  Oak  Secret  SO 


^  Alert  OflkTSra 


^AtertS0tSlB2 


^  Alert  M04  Valid  for  Role  Lecalten 


^  Me^HDtifkatiiin 


^  Alert  Oak  Secret  ]B  2 


:^AlertOakTSIS2 


OllfiBesuttiO^ 


^  Alert  SO  Secret  IB 


J^ie  R«cAtf04 


^  16  Remits  ftSOTno  AtertIB 


Term  'Alert,Nc]tfBcal]on'  SourcedL  [dick  on  that  noshing  thmg  to  continue] 
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TAtet«tiv*fUil*Map 
Kate  Q 


^labet 


Oak  Secrrtlt^  TSJB 


JllAtertWtf  Valid  fflr  Role  Ucalion 

* - '  ^A]ErtBOTSlB2 


^  AkrtJKotiflatfDn 


^AteA  Dak  Secret  ]B  2 


^Ate«tOakT$l]B2 


^  IE  ftesuHi  02 


^AlHt  SO  Secret  35 


:^IB  fl;«(Af04 


KMLittsO-3  jjMn Alert t& 


Term  'Aleit^Noti'ficatron'  Sourced,  [click  on  that  Hashing  thmg  to  cafltjnu«] 


Trttet«tiv#JUil*Msp 
Kate  ■ - Q - 


.□I  Alert  Oak  Secret  K  ^  **ert  ^0  TS  JB 


IS  Results  21  i  jHAIertWflt  Valid  lor  Hola  Location 

- '  2ii  Alert  SOTS  IB 2 


%  Al^JHotiflallDn 


^  Alert  Dak  Secret  ]B  2 


-  ^  laAlertOafcTSBi 

Q]  IB  Resulti  02 


4il  Alert  SO  Secret  IB 


^le  RtstAfOl 


^ IB  Raufts 9-3  ^HoAkAB 


Term  'Aleft,Nc]tiBcal]Dri'  Sourced,  [click  on thallla&hiing thiog  to  continue] 
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Trttet«tivieRul*Msp 
scale  ■ - Q — 


^labet 


(^i 


Term  'Alcf^Ncilificalion'  Sourced,  (click  on thallla&hiing thiog  to  continue] 
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Trttet«tiveJUil*Map 
Kate  Q - ^ 

Ci>| 

I 


0 


^  fiitA  Dais  Secret  H  ^  Alert  SO  TS  JB 


^^ISReaiitaMi 
^  Alert  OekTS  IB 


^AIertSOTSlB2 


JlJ  Alert  N'et  V«Nd  f«r  Aele  l^^celion 


^  Alert  JtertHketbn 

AM  BMi  iSS:fiErtB}iliif  FomfSan  Diego 


^  Alert  Oak  Secret  ]B  2 


:^AIertOabT$l]82 


uallBResultiOJ 


^  Alert  SO  Secret  IB 


:ilie  Rt!(AtfC<J, 


DU  IE  Rejulti  Q.3[^Mlii  Alert  b1 


9 


Rute  ‘Md  Alert  IB'  BhI  rwt  lire,  [click  on  thart  llaihrng  thin^  to  CDnlinuel 


[rttet«tivieRul*Mflp 
Kate  ■ - Q - 


^AJert  Oak  Secret  H  ^  Alert  SO  TS  IB 


IS  Reailfa  21  i 
^  Alert  OakTS  IB 


^AlertSOTSlB2 


ll  Alert  Mrtt  VaNd  f«r  H«le  Location 


^  AkrUtotHkfetiiiti 

AM  (SSy^lG)^F!M  drsm  Diego 


^  Alert  Oak  Secret  IB  2 


lUAtertOekTSBBl 


iial  IB  Reeulti  02 


^  Alert  SO  Secret  IB 


:^ie  RtScAfOl 


2il  IB  Raplti  Alert  b1 


Rule  'Alert  OaicTS  IB  2'  did  next  File.  [cEick  (xn  that  Bashing  thing  ta  ccmtinue[ 
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Kate  Q - 


^labet 


I 


0 


^  fiitA  Dais  Secret  It  ^  ^  ^0  TS  JB 


l^fltertQjfcTSiBl 


^  Alert  BO  TS  IB  2 


^  Alert  N'^t  V«Nd  f«r  Aele  l^^calion 


^  Akrt^Koiifkritiiti 

AM  BMs  isg^j£rte;^/bit  mgs 


^  Alert  Oak  Secret  ]B  2 


lUAIertCmfcTSIBZl 


Ql  IE  RsuHi  02 


^  Alert  BO  Secret  tE 


:^ie  ReiiAtfOJ, 


:3l  IE  Raolti  0.3[^  Mill  Alert  b1 


9 


Rute  ‘Alert  OalcTS  IE‘  did  FHrt  (ifA  [click  on  that  Bashing  thing  to  contmue] 


Tntet«tiv#Rul*Map 
Kate  ■ - Q - 


^AJert  Dak  Siirei  It  ^  SO  TS  JB 


IS  Resulfa  21  i 
I^AIertQafcTSBl 


2iiAlertBOTSlB2 


jli  Alert  M^t  Valid  fnr  Hnle  i^ocaiion 


^  AkrUkrtHkatiiiti 

AM  ^CAETm}fvPM^Sm  mgo 


I JLJ  Alert  Oak  Secret  IB  2] 


[UAIertOakTSIBBi 


iia]  IE  Reeulti  02 


Hi  Alert  BO  Secret  lE 


:^I8  ReftAfOl 


^  IB  Raplti  Mb  Alert  B] 


Rule 'Alert  Oak  Secret  EB  2'  did  not  Rre,  [click  on  that  Hashing  thing  to  conlinuel 
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TAtet«tiv*fUil*Map 
Kate  Q 


^labet 


flint  Oat  IB 


l^fltertOafcTSiBl 


^  Alert  BO  TS  IB  2 


^  Alert  N'^t  VaNd  f«r  Hiflie  l,«calion 


^  Akrt^Kolifkattiiti 


|^AIertOaltSeeKtlB2] 


lUfllertCmTSIBBl 


Ql  IB  Rsulti  02 


^  Alert  BO  BccrrtlB 


J^IB  ReitAtfOJ, 


Jil  IB  Rwulti  0.3[^MliiAtertBl 


9 


Rute ‘Alert  Oat  Secret  EB'  did  not  Fire,  fclkk  ofi  Chat  flashing  th^g  to  cnntintre] 


Trttet«tivieRul*Mflp 
Kate  ■ - Q - 


Alert  Oat  SecretJ-^^'^^TS  IB 


^  IS  Results  2A  i 
|,^fllertQafcTSffi| 


|^AIertSDTSB2| 


Jli  Alert  Not  Valid  for  Hole  location 


^  JUflrUtotHkatiiiti 

AM  mis  issofSETi^j^mt^sM 


IjLJAIertOafcSeeretIBZ] 


[UfltertOatTSIBBi 


iia]  IE  fteKiHi  02 


Alert  BO  Secret  IB 


J^IB  lttS(Atf04 


^  IB  Rejolti  04[^M1b  Alert  B] 


Rule 'Alert  SOTS  IB  2'  did  not  fire  (click  on  thallla&hing  thing  to  continue] 
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TAtet«tiv*fUil*Map 
Kate  Q 


^labet 


l^fltertQjfcTSiBl 


|^flleitSDTSB2| 


JIlAteftN'^t  V«Nd  f«r  Hiflie 


^  Akrt^Koiifkritiiti 


I^AIeitOaltSeeKtlBa] 


lUAIgtCmfcTSIBZl 


Ql  IB  RsuHi  02 


^AlHt  ^  Secret 


:^ie  ReiiAfOJ, 


Jil  IB  Raolti  0.3[^MiiiAtertBl 


9 


Rute  ‘Alert  SOTS  IB'  did  rwt  frfa.  [cHch  on  that  flashing  Ihin^  ta  conefnue|[ 


Trttet«tiviefUil*Mflp 
Kate  ■ - Q - 


[^AltrtOitSeci^^^SDTSIBl 


;^lSResadfa21i 

I^AIertOafcTSffil 


^  Ateft.  Not  Valid  for  Hole  location 


^IBRciuttsO 

l-:ilAteitS0SwHtB2l 


IjLJAIeitOaltSegetIBZ] 


[UAteitOatTSIB2l 


iial  IB  Reaulti  02 


Alert  SO  Secret  IB 


J^ie  lttS(Af04 


^  IB  Raplti  0.3[^NiBAtertBl 


Rute  'Alert  SO  SKret  IB  2'  did  not  file,  {click  on  that  flashing  thing  to  continue] 
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Kate  Q  - 


^labet 


0 


Hi  AlHt  Mat  Valid^  far  Rote  Location 


i^AlwtSOTSIEll 


I^AtBt0tikS«i«te2l 

I^AIcitOal(TSB2l 

f 

A 

IJAtertSOTSISl 

■  Aten,  Present,  Response 

I^AkftOtkTSIBl 

'  ^  Ateft  Notification  h  Absent! 

jj^AteftSDSecfttB 

l:JAJertS0SecietS2| 

IjJ  Alert  OffcSectetBl 

Ol  Alert  NobTicaliDn  is  Piesent 

[^KoAfertlBj 


Ryte ‘Alert  SO  SKret  IB'  lain  pmgiHi.  fclkli:  on  that  (lashing thing  to  continue] 
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Kate  Q  - 

I 

T- 

I 


^labet 


G 


r-UAtgtOritS«iitB2 

I^AItrtOritTSB2l 


Jjflteit  Not  Vaid  for  Rote  lacaikinl 

]:JAfBtS0TSIE2| 


I^AfertSOTSBi 


Aten,  Prosont ,  Rcsponso 


I^AtertOtkf^ 


'  ^  Atert  WotificaliDn  h  Absent! 


I  ^  Alert  SD  Secret  B I 


IjJ  Alert  OifcSectetBl 


IjJAtertSOSecKtBJl 

Ol  Alert  NaliricaliDn  H  Present 


[^WoAfertiij 


Rute ‘Alert  Not  Valid  for  Role  Location’  did  not  fire,  [click  on  that  flashing  Ihin^  toconEinuel 
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Kate  Q - 


^labet 


0 


i  JH  Ateft  Nrtsfmtion  1i  Pfacnt  ■ 

Aiert  Notificibon  h  Abaent  | 

^  Negate  ID  RtqwnH  to  IB  for  Mot  I 

*  Qy«y_Reqiiir«_Dato_li»efticiii 

T/ue 


^  Pofitivc  ID  Response  to  IB  for  Alert 


9 


Rute ‘Alert  Notificalnn  Is  Present'  b  in  progress,  [click  on  that  flashing  thin^  to  continue] 


Tntet«tivieRyl*Mflp 
Kate  ■ - Q — 


(^i 


[jU  Alert  Notiftcation  to  IVaginl 

Alert  Notficibon  h  Absent  | 

^Mege^  ID  Rerponai  to  tB  for  Alert  | 

>(L. 

"  QiHnyJteqdm  Oat^Jnsertkin 

Tw 


Pofitivc  ID  Response  to  IB  for  Alert 


Rute 'Alert  Notificelnn  Is  Present'  fired,  [click  on  that  flaishing  thin^  to  continue] 
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Kate  Q - 


^labet 


Q 


I  Jll  AtBt  Nrt^icafeon  ta  Pigcntl 

1^  Aiert  Notificitipn  h  Abient  | 

I-TJ  Wtqitivt  ID  RmaoriM  to  IB  for  A]«rt  I 


*  Qvciy_flrqiiir«_DataJit»rticHi 

Tfue 


Pvfitivc  ICi  Response  tv  13  for  Alert 


9 


Rute'fte^tive  ID  Response  bo  IB  forAteif  did  not  fire,  fclkkon  that  flashing  thing  to  conlinuej 


Tntet«tiv*Ryl*Mflp 
Kate  ■ - Q - 


J3J13  Reu^ltj 

[jJKcQJtiyelDBwofiMt&BfofAIrtl 


I 


IB  Results  04. 


'  IB  Rnponsc  Watt 


^IB  RBSuttsO 

5lPBe»ill»ljl 

~jPoBtivieP  Re^KMwetoPforAtefti 


Rute  'Positive  ID  Respomo  to  IB  for  Alert'  is  in  progivf  i,  (clkR  on  that  (lashing  thing  to  tontinuel 
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TAtet«tiv*fUil*Map 
Kate  Q 


^labet 


[  JJ  Nw^tive  ID  fwQfM  to  B  for  Alfft  1 


I 


:ilIBR#iulti04 


^  IB  REsponsc  Watt 

r/ijf 


|■;:jP^B^IiwlgP  BtspaoMtoBfof  Ateit] 


9 


Rute ‘Pc»(1iv«  ID  Ri»pam«tD  IB  for  Alert'  fired,  fclkic  on  IhaEflashingi  thirvg  to  continue] 


Tntet«tiv*Rul*Map 
Kate  ■ - Q - 


[jJKcQAtiyeDBwofiMt&BfofAfartI 


I 


lil  IB  Results  04 


'  IB  Rnponsc  Witt 

rnjf 


LSilBResultia 

[jJPRewiftTal 

|■::jp^^alivleP  BesponatoBfnrAteit] 


Rule  IB  RfiSulU  ?nl'did  nnt  fira.  [dick  nn  tti art  flash fng  Uiin^  to  continue| 
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TAtet«tiv*fUil*Map 
Kate  Q 


^labet 


[  JJ  Nw^tive  ID  fwQfM  to  B  for  Alfft  1 


I 


:ilIBR#iulti04 


^  ^  [ 


^aFtButeOJl 


^  IB  REsponsc  Watt 

r/ijf 


LjilB  RestiltiO 

|■;:jP^B^IiwlgP  BtspaoMtoBfof  Atert] 


9 


Rute’IB  RasuIU  Q.3'  did  rwt  [dickon  th ait  f] ashing  thin^  to  £onChnue| 


Tntet«tiv#JUil*Map 
Kate  ■ - Q - 


:aj  iG  Resiits 


li:JPR«utenl 


%  Re1ijn^IB_Resulb 


'LaiigRcnrt&0.2l 


Rute  IB  RfSulU  0,2'  is  tn  pmgms.  (click  on  that  lla&hiing  thidg  to  continue] 
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TAtet«tiv*fUil*Map 
Kate  Q 


^labet 


IzJIBRtsuHt^ 


■fe  Rdun^IB^ResuHs 


2 


(ISIIBRmuIUD 


9 


Rute  ’IB  RasuIU  0.2'  ia  m  pmgrefE.  (click  on  th^l  Hashing  thmg  to  cafltjnu«] 


Trttet«tiv#Rul*Mfip 
Kate  ■ - Q - 


:aj  IB  Rtsiit; 


.:3JI&  Reivlucs.1 


l::JIBIteulteZl] 


^ISRkuHiS 


»fc  Rplum  IB  Retuto 

KmoT  A*ub  Aw  UximMfB  ^  m  tioeeoftfyeS^ 


'LaiigRcnrt&0.2l 


IS 


Rute  IB  RfSulU  0.2'  ii  m  pmgms.  (click  on  that  lla&hiing  thmg  to  continue] 
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TAtet«tiv#fUil*Map 

Kate  [J 


^labet 


|^ERKtiti2l| 


■aJPRwuteOji 


%  Re1uni_IB_R«ull± 

AuKr  Aw  iJhdIttaiStfi/f  i^^BceoflArSi 


l^aiusufa^ 


<31  IS  Reiiiltjdl 


Rute  ’IB  RasuIU  0.2'  ia  tn  pmgir«£.  (click  on  th^l  Hashing  thmg  tc  cafltjnu«] 


Trttet«tivieRul*Map 
Kate  ■ - Q - 


|.:JERestJtii2l| 


%  Reiun^IBJReHjIb 

Aw  tJheAtaHKi/e  )t«>  £7  tjAceoftAfSai 


I^BIUsufa^ 


0136  RHtiItjOl 


Rute  IB  RsulU  0.2'  filled,  [click  on  that  Fleshing  thin^  (o  continue] 
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APPENDIX  E.  RULE  TRACE  OF  OTHER  QUERIES  NOT 
SUPPORTED  (INVALID  QUERY) 


The  visual  trace  of  the  ruleset  execution  was  used  to  show  non-support  for  actions 

that  are  not  accounted  for  in  the  scenario  and  thus  our  ruleset.  This  is  for  items  that  are 

considered  invalid  by  our  security  policy  and  should  not  return  a  valid  result  from  the 

ruleset.  This  trace  is  completed  using  the  following  parameters: 

Type  of  query:  Destination  Port 

Role  /  Actor:  Harbormaster 

Location:  Shanghai 

Security  Level:  Unclassified 

Alert  Present:  False 

Alert  Classification  Level:  Not  Applicable 
Expected  Result:  “Invalid  Query” 


The  expected  result  from  this  query  and  the  RuleML  execution  is  an  IB  response  of 
“Invalid  Query”  to  the  user.  The  trace  was  completed  using  RuIeManager’s  Interactive 
Rule  Map  functionality.  The  pop-up  boxes  shown  throughout  the  trace  indicate  the 
sourcing  of  predicates  that  would  be  included  with  tagged  data  in  a  live  system.  This  was 
not  replicated  for  this  research  and  instead  was  manually  inserted  via  the  dialog  boxes. 

For  the  rule  trace  shown  and  from  the  interactive  rule  map  of  RuleManager, 
various  indicators  are  used  to  show  the  actions  during  the  trace.  A  rule  or  variable 
highlighted  in  Yellow,  indicates  that  a  rule  or  variable  is  currently  being  sourced.  A  rule 
depicted  in  Red  indicates  that  the  rule  did  not  fire  (execute)  from  the  ruleset.  A  rule 
shown  highlighted  in  Green  indicates  that  the  rule  did  fire  and  the  result  of  that  firing  is 
also  shown  in  the  green  highlighted  box  with  the  predicate  name.  Pop-up  dialog  boxes 
shown  in  the  trace  indicate  the  sourcing  of  a  variable  or  predicate  that  would  be  done  by 
an  external  entity  (service)  or  taken  from  XML  attributes  attached  to  the  query  upon 
origination  (i.e.,  user  role  and  user  security  level). 
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